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1.1  Introduction 

The  United  States  Coast  Guard  has  been  tasked,  under  law,  with 
providing  Search  and  Rescue  (SAR)  services  to  people  and  property  in  peril  on 
the  high  seas  or  in  waters  subject  to  the  jurisdiction  of  the  United  States. 
This  mission  entails  a large  expenditure  of  manpower  and  equipment  to  meet  the 
growing  demands  for  service.  Management  of  the  SAR  resources  is  becoming 
increasingly  difficult  as  the  system  becomes  more  complex.  SAR  managers  are 
tasked  with  the  problem  of  meeting  demands  in  an  effective  and  economical 
manner  without  sacrificing  the  quality  of  services  rendered. 


The  management  of  the  SAR  system  requires  that  frequent 

consideration  be 

given  to: 

a. 

Funding  justification 

b. 

Manning  levels 

c. 

Reducing  operating  costs 

d. 

Selection  of  replacement  equipment 

e. 

Fluctuations  in  demands  for  services 

f . 

Operational  policies  which  directly  affect  resource 
utilization 

SAR  management  problems  are,  in  essence,  concerned  with  allocation 
of  limited  resources  with  the  goal  of  .achieving  desired  levels  and  standards 
of  performance.  Thus,  decisions  may  be  required  with  regard  to: 

a.  Establishment,  relocation,  or  disestablishment  of  shore 
stations  or  air  stations 

b.  Relocation  of  resources  or  changes  in  the  mix  of  available 
resources 

c.  Changes  in  manning  levels 

d.  Introduction  of  resources  as  replacement,  or  in  addition 
to  existing  resources 

e.  Actions  in  anticipation  of  significant  changes  in  demands 
for  services 

f.  Operational  policies  which  directly  affect  resource 
util ization. 


1.2  3ackqround 

The  Search  and  Rescue  Simulation  (SARSIM)  was  originally  developed 
under  a joint  effort  between  the  Coast  Guard  and  the  National  Bureau  of 
Standards  between  1963  and  1972.  The  early  version  was  written  in  SIMSCRIRT 

1.5.  It  was  used  operationally  by  planners  at  Coast  Guard  Headquarters  from 
1972  until  1975.  During  this  period,  the  Coast  Guard  Research  and  Development 
Center  (R&OC)  at  Groton,  Connecticut,  used  SARSIM  in  several  projects 
involving  resource  evaluation.  In  September  1975,  the  R1DC  was  tasked  with  a 
project  to  uDdate  and  modify  SARSIM.  Early  project  work  was  done  on  a UNIVAC 
1108  at  the  Naval  Underwater  Systems  Center  and  then  shifted  to  Control  Data 
Corporation,  CY3ERNET,  in  late  1977.  The  new  version  is  written  in  SIMSCRIRT 

11. 5.  SARSIM  is  currently  being  used  at  Coast  Guard  Headquarters  in 
Washington,  0C. 
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1.3  The  Search  And  Rescue  Process 


In  order  to  meet  the  needs  of  persons  and  property  requiring  search 
and  rescue,  the  U.S.  Coast  Guard  establishes  stations  and  resources  at 
strategic  locations  along  the  coasts  and  in  certain  rivers/lakes  of  the 
continental  United  States,  Hawaii,  and  Alaska.  In  1977,  the  inventory  of 
resources  consisted  of  201  SAR  stations,  26  air  stations,  1S00  boats,  142 
cutters,  147  aircraft,  and  11,369  mi  1 itary  personnel . These  units  responded 
to  over  74,000  distress  calls;  directly  saving  the  lives  of  nearly  4,200 
persons,  and  assisting  property  valued  at  over  S2.9  billion.  Additionally, 
assistance  was  rendered  to  over  182,000  persons  in  non-severe  situations. 

This  caseload  is  increasing  at  about  6 percent  per  year. 

Typical  SAR  cases  evolve  in  the  following  manner: 

a.  The  U.S.  Coast  Guard  receives  information  that  someone  is 
in  distress  or  needs  assistance. 

b.  The  requirements  of  the  case,  including  weather 
conditions,  type  of  unit  in  distress,  location,  types  of 
service  needed,  etc.,  are  evaluated. 

c.  From  the  inventory  of  nearby  resources,  one  or  more 
available  and  capable  resources  are  dispatched. 

d.  If  resources  are  not  immediately  available,  the  case  may 
have  to  be  queued  until  resources  can  be  dispatched  or 
resources  are  interrupted  from  other,  less  severe,  cases 
and  diverted  to  the  new  case. 

e.  Some  cases  require  searching  before  assistance  can  begin. 
Many  cases  require  towing  after  assistance  has-been  > • 
rendered. 

f.  Upon  completion  of  the  case,  resources  return  to  their 
home  stations  to  become  available  for  other  cases,  or  go 
directly  to  another  case. 

1.4  Overview  Of  The  Simulation 


The  Search  and  Rescue  Simulation  (SARSIM)  is  a management  tool  that 
has  been  developed  to  aid  Coast  Guard  decision-makers  in  developing  long-range 
strategic  plans  to  carry  out  the  SAR  mission.  SARSIM  is  a discrete  event 
digital  computer  simulation  program  programmed  in  SIMSCRIPT  II. 5.  It  is  a 
highly  flexible  user-oriented  model  that  simulates  Coast  Guard  response  to 
futuri'tic  caseloads. 

In  simplest  terms,  the  search  and  rescue  model  exemplifies  a typical 
waiting  line  problem  wherein  customers,  i.e.,  cases  requiring  Coast  Guard 
services,  enter  the  system  at  random  times  to  be  serviced  by  one  or  mere 
facilities,  i.e.,  Coast  Guard  resources.  A customer  being  serviced  ties  up 
one  or  more  servicing  facilities  for  an  amount  of  time  dependent  on  the 
location  of  the  case  and  the  type  and  amount  of  service  required. 

Accordingly,  new  customers  may  arrive  in  the  system  and  have  to  wait  (in  a 
queue)  until  an  appropriate  facility  is  released  on  completing  its  last 
service  or,  perhaps,  priorities  may  require  breaking  off  service  in  progress, 
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putting  the  less  serious  case  into  a queue.  On  the  one  hand,  the  desire  to 
satisfy  "customers"  might  occasion  the  acquisition  of  enough  service 
facilities  to  keep  queuing  and  waiting  time  to  a minimum.  However,  it  might 
be  considered  unacceptable  if  expensive  facilities  were  maintained  in  3 
standby,  but  idle,  condition  to  achieve  the  aforementioned  objective.  Central 
to  this  problem,  moreover,  is  the  random  nature  of  the  arrivals  and  servicing, 
hence  the  need  to  balance  requirements  for  long-term  satisfaction  of  needs 
with  the  possibility  of  temporary  overloading  of  the  system  during  peak 
periods  or  unusual  circumstances. 


The  simulation  is  keyed  to  specific  events , such  as  the  arrival  of 
cases  requiring  service,  assignment  of  resources  to  these  cases,  interruption 
of  service  by  an  assigned  resource  which  must  be  reassigned  to  a case  of 
greater  severity,  completion  of  service  by  one  or  more  assigned  resources, 
handoff  of  a tow,  recall  of  crews,  etc.  Consequently,  operation  of  the 
program  proceeds  from  one  significant  event  to  the  next,  with  an  internal 
(simulated)  clock  keeping  track  of  the  simulated  passage  of  time.  Thus  the 
simulation  allows  time  to  be  compressed  and  a month  of  cases  can  be  processed 
in  a few  minutes  on  the  computer. 

SARSIM  is  comprised  of  three  major  modules.  The  first  major  module 
is  the  PREPROCESSOR.  The  PREPROCESSOR  is  used  to  generate  expected  caseloads 
based  on  the  historical  SAR  Data  3ase.  In  other  words,  it  supplies  a 
scenario,  or  futuristic  caseload  which  may,  if  desired,  be  used  for  many 
different  simulation  runs. 

The  heart  of  SARSIM,  the  SIMULATOR,  is  essentially  a bookkeeping 
system  which  logs  in  cases,  registers  their  needs,  investigates  the 
avai.labiliJty.  o*.»er-v.ice  .fac-iM’ties,  assigrrs  resources  for  servicing',  and*'* 
generally  keeps  track  of  simulated  time  spent  in  the  several  possible 
activities  represented  within  the  model  and  maintains  statistics  for  output. 
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2.0  THE  PREPROCESSOR 


The  preprocessing  of  the  data  in  the  SAR  Data  3ase  to  generate  futuristic 
caseloads  is  accomplished  in  four  phases.  Phase  1 selects  from  the  SAR  Oata 
Base  those  elements  of  each  SAR  record  which  will  be  of  use  in  subsequent 
processing.  Phase  2 creates  data  tapes  which  will  serve  as  input  for  the 
Phas<*  3 processing.  Phase  3 consolidates  cases,  classifies  cases,  and  gathers 
basic  statistics  to  be  used  in  Phase  4.  Phase  4 creates  futuristic  case  files 
which  serve  as  input  to  the  SIMULATOR. 

2.1  Phase  1 - SAR  Oata  3ase  Processing 

The  raw  data  base  for  SARSIM  is  the  SAR  data  base  maintained  by 
Commandant  (G-OSR).  These  coded  data  are  extracted  from  SAR  Assistance 
Reports  (CG-3272  and  CG-3272A)  which  are  filed  for  each  SAR  case  which  is 
prosecuted  by  the  Coast  Guard.  A sample  Assistance  Report  from  CG-397,  Search 
and  Rescue  Reports  Manual  (Reference  3)  is  included  as  Figure  2.1.1. 

The  basis  for  selecting  data  as  input  to  this  version  of  SARSIM  was 
the  National  3ureau  of  Standards  model.  Reference  1,  Volume  II.  No  attempt 
has  been  made  to  do  a serious  data  analysis  of  the  SAR  data  base  to  determine 
what  elements  of  the  data  base  are  highly  correlated  and  thus  redundant. 

Figure  2.1.2  shows  the  elements  in  a record  of  the  SAR  data  base, 
also  indicated  are  those  elements  which  are  selected  for  input  into  Phase  2. 
The  data  for  Phase  2 are  abstracted  from  the  "sixteen"  file  of  the  Master  SAR 
Data  Base  File  which  is  organized  by  district/area  and  OPFAC.  One  fiscal  year 
of  data  is  processed  at  a time.  The  data  processing  is  accomplished  via  a 
..  UT-L4  progr.am,  .which . is.  submitted  ..by  tbe  SAR  Qata  Base  Coordinator. 

The  end  result  of  this  preliminary  processing  is  a magnetic  tape(s) 
with  one  fiscal  year  of  data  for  the  entire  Coast  Guard.  The  data  is  sorteo 
by  district/area,  but  it  is  all  in  one  file. 

2.2  Phase  2 - Creation  Of  Scooe  Oata  Tapes 


The  main  purpose  of  this  phase  is  to  copy  the  file  of  SAR  data  *rom 
Phase  1,  from  Coast  Guard  computer  tapes  to  Cybernet  Scope  computer  tapes, 
counting  the  records  and  placing  end-of-file  marks  between  each 
district/area.  This  is  accomplished  through  the  use  of  the  TRANZ  Program. 

See  Reference  11.  The  output  files  are  passed  to  Phase  3 for  further 
processing. 

2.3  Phase  3 - Case  Consolidation  And  Classification 


The  main  purposes  of  this  phase  are  case  consolidation  and  case 
classification.  This  is  accomDlished  through  the  use  of  a computer  program 
called  the  Data  Preparation  Member  (0PM).  See  Reference  i2.  Case 
consolidation  is  a fairly  complex  process  and  will  be  discussed  in  detail 
below.  Cases  are  classified  along  three  dimensions:  search  versus  nonsearch; 
peak  versus  off peak;  and  weekday  versus  weekend. 
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Classification  of  a case  as  a search  case  is  a straightforward 
process.  All  of  the  demand  for  service  cooes  (C.38  and  C.39  defined  in 
Reference  3)  on  a case  are  examined  and  if  the  C.08  equals  1,  2,  or  3,  or  C.39 
equals  I or  2,  then  the  case  is  classified  as  a search  case.  Search  cases  are 
separated  from  nonsearch  cases  due  to  qualitative  differences  in  the 
processing  of  the  two  types  of  cases  in  the  SIMULATOR 

The  peak/off peak  division  of  cases  is  at  the  SARSIM  analyst's 
discretion,  i.e.,  the  analyst  defines  peak  and  offpeak  periods.  The 
distinction  is  desirable  because  of  the  rather  dramatic  change  in  case  volume 
which  occurs  in  peak  periods. 

The  weekday/weekend  classification  is  also  based  on  case  volume, 
with  volume  being  signif icantly  greater  on  weekends,  which  are  defined  as 
Saturdays,  Sundays,  and  holidays. 

In  the  SAR  data  base,  every  unit  that  responded  to  a case  files  a 
report  which  becomes  a sortie  record  in  the  SAR  data  base.  If  only  one  unit 
responds  to  a case,  then  onl-y  one  sortie  record  exists  in  the  data  base,  but 
if  more  than  one  unit  responds,  things  get  more  complicated,  especially  since 
there  are  several  types  of  multi -unit  cases. 

3asically,  the  0PM  wants  to  find  all  the  sorties  associated  with  a 
case,  set  background  case  parameters,  such  as  weather,  case  location,  etc., 
and,  most  important,  come  up  with  a list  of  the  demands  for  service  (Codes 
C.38  and  C.39  in  Reference  3)  with  which  the  responding  unit(s)  dealt.  Figure 
2.3.1  shows  the  case  characteristics  which  are  set  in  the  0PM. 

For  the  actual  consolidation  process,  the  record  code  is  used 
extensively.  It  is  first  used  to  determine  what  kind  of  case  we  are  dealing 
with  and  then  it  is  used  for  the  processing  of  the  sorties.  There  are  four 
kinds  of  cases:  (I)  single-station,  single-sortie;  (2)  single-station, 
mul ti-scrtie;  (3)  multi-station;  and  (A)  area.  Single-station  cases  have  a 
header  record  code  equal  to  3,  and  if  the  number  of  sorties  is  greater  than  1, 
it  is  a single-station  multi-sortie  case,  otherwise  it  is  a single-station, 
single-sortie  case.  On  a single-station,  multi-sortie  case,  all  the 
subsequent  sorties  have  a record  code  equal  to  10,  and  to  make  certain  that 
only  the  sorties  for  this  case  are  processed,  the  unit  case  number  is  checked 
for  all  sorties.  7ne  number  of  sorties  coda  is  not  used  to  check  for  the 
number  of  sorties  because  of  the  possibility  of  the  omission  of  some  sortie 
records  from  the  data.  For  multi-station  and  area  cases  there  is  no  header  as 
such  in  the  data  file  which  is  being  input;  however,  the  record  code  for  the 
first  sortie  in  these  cases  is  equal  to  4 or  3.  Subsequent  sorties  for  a 
given  station  have  record  code  equal  to  10  or  11,  then  the  next  stations  first 
sortie  record  again  has  a record  code  of  4 or  3,  with  the  sortie  having  a 
record  code  of  10  or  11.  To  insure  that  two  multi-station  or  area  cases  which 
occur  together  in  the  data  are  actually  separated  in  processing,  the 
multi-unit  case  numoer  is  checked  for  each  sortie  processed.-' 


The  nature  of  the  simulation  process  requires  that  the  system  to  be 
simulated  be  simplified,  what  this  means  is  that  certain  real-world  situations 
or  data  may  have  to  oe  omitted  from  the  simulation.  In  performing  the  case 


consolidation  procass,  the  0PM  also  screens  the  data  to  insure  that  only 
useful  data  is  passed  to  the  next  phase.  Sortie  racoras,  and  in  certain 
instances,  whole  cases  may  be  deleted  from  the  aata  base.  The  reasons  for 
sortie/case  deletion  are  described  below. 

One  or  the  first  constraints  placed  on  the  data  is  that  the  cases 
all  occur  in  the  geographical  area  of  interest.  This  area  is  specified  by  the 
user  in  two  ways.  The  first  way  is  by  selecting  the  di stricts/areas  to  be 
processed.  The  second  way  is  by  specifying  a geographical  area  such  that 
cases  outside  of  this  area  are  excluded  from  cons id°rat ion . 

Next,  cases  are  screened  to  see  if  the  assisting  resource,  which 
responded  to  the  case  ( C . 01  codes  in  Reference  3),  is  one  which  the  user  has 
designated  as  one  which  will  be  simulated.  If  it  is  not,  then  the  sortie  for 
that  resource  is  deleted  and  if  all  the  sorties  on  a case  are  deleted,  then  so 
obviously  is  the  case,  since  the  demands  for  service  are  obtained  frcm  the 
sortie  records.  Examples  of  the  types  of  assisting  resources  which  might  not 
be  simulated  are  land  vehicles  (Code  00)  and  auxiliary  (Code  90). 

One  type  of  case  which  is  not  simulated  is  one  in  which  two 
distressed  units  are  aided  simultaneously.  This  type  of  case  has  a record 
code  of  20  and  all  cases  with  this  record  code  are  omitted  from  consideration . 

Another  reason  for  case  deletion  is  if  there  are  too  many  sorties  on 
a case.  The  number  of  sorties  which  is  considered  too  many  is  set  by  the 
analyst.  The  basic  reason  for  deleting  these  cases  is  that  they  occur  very 
infrequently  and  thus,  if  one  occurred  during  a given  run  of  the  SIMULATOR,  it 
could  bias  the  results. 

Oetermi nation  of  the  number  of  sorties  on  a case  is  a complicated 
procass  in  that  it  is  different  depending  on  whether  we  have  a single-station 
or  multi-station  case.  For  single-station  cases,  if  the  number  of  soroies 
given  in  the  header  record  is  greater  than  1,  then  we  have  a multi-sortie 
case.  Further,  it  is  expected  that  the  record  after  the  header  will  be  a 
sortie  record  for  the  case  we  are  processing,  with  a record  code  of  10  and  the 
same  unit  case  number  as  the  header.  If  it  is  not,  then  the  case  is  deleted. 
If  it  is,  then  all  sorties  with  a record  code  of  10  and  the  same  unit  case 
number  are  processed  and  counted. 

For  multi -station  cases,  the  sorties  are  determined  by  an 
examination  of  multi-unit  case  number  and  all  sorties  with  this  case  number 
are  included  in  the  case.  Again,  if  too  many  sorties  are  encountered,  the 
entire  case  is  deleted. 

The  remainder  of  the  processing  of  mul ti-station/area  oases  is 
complicated  in  that  the  particular  SAR  data  file  we  are  using  has  no  header 
records  and,  even  if  it  did,  these  would  be  of  questionable  value  since  they 
would  contain  optimized  data  for  the  case.  This  ootimized  data  would  be  fvr 
the  most  effective  resource  on  the  case  and  not  necessarily  for  the  first 
resource  dispatched.  As  far  as  the  simulator  is  concerned,  it  is  assent', al 
that  we  know  the  time  at  which  the  first  facility  on  the  case  was  notified. 
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We  would  also  like  the  weather  conditions  for  the  case  to  be  the  worst 
encountered  by  any  resource  on  the  case.  The  location  of  the  case  should  be 
as  good  as  possible  and  it  is  felt  that  the  last  resource  on  the  case  probably 
has  the  best  idea  of  where  the  case  actually  occurred.  The  point  is  that  data 
must  be  gathered  from  various  sorties  which  constitute  a multi-station  case. 

Cases  are  sub-classified  as  routine  or  severe,  this  is  acccmolished 
by  examining  the  severity  of  distress-p  sonnel  code,  B . 29  (in  Reference  3), 
and  the  severity  of  distress-property  code,  8.10  (in  Reference  3).  If  the 
personnel  code  is  equal  to  2 or  3,  and/or  the  property  code  is  equal  to  3, 
then  the  case  is  classified  as  severe,  otherwise  the  case  is  considered 
routi ne . 


Timing  on  a case,  which  was  alluded  to  above,  is  important  in 
several  of  the  calculations  to  be  detailed  below  and  a complicated  algorithm 
is  employed  to  insure  that  the  times  (notified,  underway,  on  scene)  on  a case 
are  consistent.  For  details  of  this  algorithm,  see  Reference  12,  Page  22. 
Basically,  the  algorithm  insures  that  the  time  notified  proceeds  the  time 
underway  and  that  the  time  underway  preceeds  the  time  on  scene  with  the  time 
notified  being  accepted  apriori  as  correct. 

Demands  for  service  (C.08  and  C.09  codes)  are  entered  as  a pair  on  a 
sortie  record.  There  are  some  20-C.08  codes  and  34-C.09  codes  which  means  530 
possible  demand  pairs  but  only  about  150  show  up  in  a typical  0PM  run  with 
only  the  first  20  or  so  pairs  having  a significant  frequency  of  occurrence.  * 
Air  escort,  stoodby,  and  air  escort  are  created  in  the  DPM  to  preserve  the 
fact  that  these  were  responded  to  by  an  aircraft  and  that  is  wny  there  are  34 
instead  of  32  property  demands  (C.09).  What  is  desired  here  is  some  way  of 
ascertaining  the  average  service  time  and  standard  deviation  for  the  more 
important  demands.  So  for  each  demand  pair  type  which  occurs  in  the  0PM  data, 
a service  time  for  the  demand  pair  is  calculated  by  assuming  that  transit  time 
to  return  from  the  case  is  equal  to  the  transit  time  enroute  to  the  case,  thus 
service  time  for  a demand  pair  is  equal  to  total  time  on  sortie  (C.07)  minus 
twice  the  transit  time  (time  on  scene  - time  underway).  The  validity  of  the 
twice  the  transit  time  assumption  has  not  been  verified  to  the  author's 
knowledge.  The  program  keeps  running  totals  of  the  service  times  and 
frequency  of  occurrence  of  the  various  demand  pairs  and  as  part  of  an  output 
report  displays  the  mean  service  time  and  standard  deviation  for  each  demand 
pair  which  was  encountered  in  the  data. 

The  data  which  is  input  to  the  0PM  can  be  up  to  three  fiscal  years 
of  SAR  data  from  one  or  two  districts  and  an  area.  In  larger  districts,  like 
District  3,  only  two  years  of  data  can  be  input  at  present  due  to  a core 
memory  shortage  in  the  computer  system  on  which  the  model  is  presently 
i nstal 1 ed . 


Timing  information  is  also  used  for  calculation  of  total  search  time 
on  a case  which  is  the  sum  of  the  service  times  for  all  resources  involved' in 
a search.  Search  time  for  a resource  is  considered  to  be  the  total  service 
time  for  that  resource  on  a sortie.  Thus  total  search  time  includes  not  only 
time  spent  searching  but  the  actual  service  time  of  any  demanas  serviced  which 
is  an  overestimate  but  it  was  decided  by  G-QSR  that  this  would  not  result  in 
significantly  elevated  response  times  in  the  SIMULATOR. 
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Total  search  time  is  used  to  calculate  total  search  miles  for  a case 
which  is  obtained  by  adding  together  the  product  of  total  search  time  and 
search  speed  for  each  resource  on  a case-  Note  that  it  is  assumed  that  a 
linear  mile  traveled  by  one  type  of  resource  is  equal  (in  search  area 
coverage)  to  a linear  mile  for  another  type  of  resource,  which  is  generally 
consistent  with  the  SAR  Manual  sweepwidth  tables  and  overall  purpose  of  SARSIM 

The  final  function  of  the  0PM  is  to  calculate  an  occurrence-per-day 
histogram  for  each  time  period  and  search/nonsearch , weekday/weekend, 
classification  of  cases.  An  occurrence-per-day  histogram  can  be  thought  of  as 
a table  with  pairs  of  entries.  The  first  entry  of  a pair  is  an  integer,  say 
J,  and  represents  an  exact  number  of  cases  which  occur  on  a given  day.  The 
second  number  of  the  pair  (Pj)  is  the  probability  that  exactly  J cases  will 
occur  on  any  given  day  in  a particular  period  of  time.  To  calculate  the 
probability,  Pj,  of  J cases  occurring  on  a given  day,  it  is  necessary  to 
know  two  things:  (1)  the  number,  Kj,  of  days  in  the  period  of  time  being 
considered  which  had  exactly  J cases  occur  and  (2)  the  total  number,  N,  of 
days  in  the  period  of  time  being  considered.  The  calculation  of  Pj  is  then 
straightforward:  Pj3Kj/N  and  the  table  entry  is  the  pair  (J,  Pj). 

Note:  The  summation  of  the  Kj's  from  J=0  to  M is  equal  to  N,  where  M is  the 
maximum  number  of  cases  which  occurred  on  any  day  within  the  period  of  time 
being  considered  and 


) ^ 1 


The  occurrence-per-day  histograms  are  used  in  the  OEM  to  determine 
the  number  of  cases  to  select  on  any  given  day.  This  is  described  further  in 
the  next  phase  (Section  2.4). 

For  output,  the  0PM  produces  a printed  report  and  ten  mass  storage 
files  which  are  placed  on  magnetic  tape'.  The  printed  report  summarizes  the 
reasons  for  sortie  or  case  deletion  (discussed  above);  displays  the  number  and 
kinds  of  good  cases  written;  presents  an  exhaustive  list  of  the  demand  pairs 
(discussed  above)  encountered,  their  frequency,  mean  service  time,  and 
standard  deviation;  finally,  several  tables  displaying  the  distributions  of 
various  case  parameters  are  given. 

The  case  parameter  distributions  displayed  include:  geographical 
area,  seastate,  visibility,  distance  offshore,  tonnage,  demands  for  service, 
demand  by  seastate,  and  demand  by  patron.  These  distributions  are  all 
presented  for  peak-offpeak , search-nonsearch , and  severe-routine  categories. 

The  ten  files  are  divided  into  two  sets  of  five  files,  one  set  is 
for  peak  period  cases  and  the  other  set  is  for  offpeak  period  cases.  Each  set 
consists  of  two  keycode  files,  one  for  search  and  one  for  nonsearch  cases;  two 
case  fil.s,  again,  one  for  search  and  one  for  nonsearch;  and  a statistics  *i!e 
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The  keycode  files  are  used  in  the  next  phase  to  reduce  the  number  of 
C/0  operations  in  the  case  selection  process.  The  case  files  preserve  all  the 
details  of  a case.  The  statistics  file  transfers  basic  initializing 
information,  which  includes  the  occurrence-per-day  histograms  discussed  above. 

2.4  Phase  4 - Creation  Of  Futuristic  Case  Files 


The  main  purpose  of  this  phase  is  to  produce  event  files  which  will 
be  used  as  input  to  the  SIMULATOR.  This  is  accomplished  through  the  use  of  a 
computer  program  called  the  Originate  Events  Member  (OEM).  The  major 
character! sti cs  of  the  search  and  nonsearch  event  files  which  are  created  by 
the  OEM  are  specified  by  the  SARSIM  analyst.  The  characteristics  which  can  be 
manipulated  include:  number  of  days  to  be  simulated;  overall  caseload:  the 
mix  of  distressed  units;  the  distance  offshore  in  which  cases  occur; 
alteration  of  case  occurrence  in  a particular  area;  specification  of  demand 
types;  and  modification  of  demand  types  in  a particular  area. 

The  goal  of  the  OEM  in  the  default  mode  is  to  produce  event  files  of 
SAR  cases  in  which  all  basic  SAR  population  characteristics  are  replicated. 
This  goal  is  accomplished  via  a random  selection  process  among  the  several 
years  of  case  data  which  is  used  as  input  to  the  OEM. 

The  input  data  as  explained  in  Section  2.3  is  divided  into  peak 
versus  off peak,  search  versus  nonsearch,  and  weekday  versus  weekend/hol iday 
categories.  A given  run  of  the  OEM  would  involve  either  peak  or  offpeak  cases 
in  the  remaining  four  categories.  Search  and  nonsearch  cases  are  processed 
separately  but  in  an  analogous  fashion,  therefore,  only  the  processing  of 
nonsearch  cases  will  be  described  here. 

The  basic  problem  is  to  select  say  30  days  of  representative  cases. 
This  is  accomplished  utilizing  the  occurrence-per-day  histograms  discussed  in 
Section  2.3.  Case  selection  is  accomplished  on  a daily  basis  and  the  number 
of  cases  to  select  on  any  given  day  is  resolved  by  random  selection  in  the 
occurrence-per-day  histogram  which  is  appropriate  for  the  kind 
(weekday/weekend)  of  day  for  which  cases  are  to  be  selected.  3as i c al 1 y , the 
occurrence-per-day  histogram  allows  between  0 ago  M cases  to  happen  on  any 
given  day  where  M is  the  maximum  number  of  cases  which  occurred  on  any  given 
day  of  the  type  (weekday/weekend)  which  we  are  considering.  For  each  number 
of  cases  which  can  occur,  a probability  has  been  determined  as  explained  in 
Section  2.3  and  from  these  probabilities  a cumulative  probability  distribution 
has  been  calculated.  The  cumulative  distribution  has  probabilities  ranging 
from  0 to  1,  thus  for  each  number  of  cases  from  0 to  M which  can  occur,  there 
is  a probability  band  associated  with  it  and  by  entering  the  probability 
distribution  with  an  uniform  (0,1)  random  number,  a number  of  cases  to  select 
for  the  day  can  be  determined.  This  method  of  determining  the  number  of  cases 
to  select  on  a day,  preserves  the  natural  variability  in  case  occurrence  which 
occurs  from  day  to  day. 

Once  the  number  of  cases  to  select  has  been  determined,  then  that 
number  of  cases  is  selected  randomly  and  with  replacement  from  the  pool  of 
cases  of  that  type,  e.g.,  peak,  nonsearch,  weekday  cases.  This  random 
selection  process  should  replicate  the  distributions  or  all  of  the  basic  case 


parameters,  and  in  fact,  the  distributions  for  location,  type  of  distressed 
unit,  seastate,  visibility,  distance  offshore,  tonnage  of  distressed  unit,  and 
demands  for  service  have  been  verified;  see  Reference  15.  The  time  of  day  at 
which  cases  occur  is  kept  with  the  cases,  this  was  done  so  that  no  analysis  of 
case  type  by  time  of  day  would  be  necessary. 

Once  a case  has  been  selected,  certain  characteristics  of  the  case 
are  obtained  directly  from  the  OPM-created  case  file  and  other  characteristics 
represent  modification  or  additions  to  that  basic  data.  Figure  2.4.1  shows 
all  the  items  which  make  up  a case  in  the  event  file;  there  are  slight 
differences  between  the  search  and  nonsearch  files  and  these  are  indicated, 
also  indicated  are  those  items  which  were  modified.  The  items  which  must  be 
modified  or  added  are  of  three  sorts:  (1)  items  which  were  coded  in  the  SAR 
data  base  and  must  be  converted  to  real  values;  (2)  the  total  number  of 
demands  is  to  be  reduced  and,  therefore,  a conversion  process  must  be  carried 
out;  (3)  service  times  for  demands  for  service  are  also  assigned  in  the  OEM. 

The  uncoding  of  coded  items  is  straightforward  and  virtually 
identical  for  all  coded  items.  The  items  which  must  be  uncoded  include: 
seastate,  wind  speed,  visibility,  distance  offshore,  and  tonnage.  Let  us 
examine  the  conversion  of  a typical  code  to  a real  value.  Each  code  value, 
except  for  the  unknown  code,  represents  a range  or  class  of  real  values  which 
the  characteristic  in  question  may  take  on  and  since  there  is  no  information 
available  about  the  distribution  of  real  values  within  a class,  a uniform 
distribution  is  assumed  and  assignments  of  real  values  are  made  accordingly. 
Thus,  if  for  a code  value  of  "5,"  the  range  of  real  values  is  "24"  to  "36" 
then  a value  of  between  "24"  and  "36"  is  selected  utilizing  a uniform 
distribution.  Table  2.4.1  shows  the  code  and  class  values  for  each  of  the 
variables  listed  above. 


The  tonnage  variable  deserves  special  mention  as  it  is  actually 
derived  from  the  length  of  distressed  unit  code,  8.19,  in  Reference  3.  The 
length  code  is  first  converted  to  a length  in  the  usual  way  and  then  a formula 
is  used  to  convert  the  length  to  a tonnage,  namely  tonnage  equals  length  cubed 
divided  by  6400. 

The  unknown  codes  for  all  variables  are  assigned  a code  value  based 
on  the  frequency  of  occurrence  of  each  of  the  remaining  code  values  for  the 
variable,  i.e.,  the  distribution  of  codes  which  have  known  real  values  is 
determined  by  the  SARSIM  analyst,  input  to  the  OEM,  and  when  the  unknown  coda 
occurs,  a new  code  value  is  assigned  utilizing  a uniform  (0,1)  random  number 
and  the  analyst-defined  distribution.  Thus  unknowns  are  redistributed  among 
the  known  codes,  preserving  the  distribution  of  known  codes. 


The  demand  for  service  codes  (C.08  and  C.09)  are  reduced  to  a 
realistic  level  through  the  efforts  of  the  SARSIM  analyst.  The  analyst 
supplies  the  conversion  scheme  at  OEM  run  time.  For  details  of  the 
specification  process,  the  interested  reader  should  consul t .Reference  10 
and/or  Reference  13. 


The  assignment  of 
supplied  means  and  standard 
service  time.  Some  demands 


service  times  is  based  on  the  SARSIM  analyst's 
deviations  for  each  of  the  demands  requiring  a 
such  as  "tow"  do  not  require  a service  time 
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because  the  service  time  for  a "tew"  is  determined  by  the  SIMULATOR.  When  a 
service  time  is  needed,  the  gamma  distribution  is  sampled,  utilizing  the  mean 
and  standard  deviation  supplied  by  the  analyst. 

The  remaining  items  which  need  to  be  discussed  regarding  processing 
in  the  OEM  are  concerned  with  those  characteristics  of  a caseload  which  can  be 
altered  by  the  SARSIM  analyst.  Items  included  here  are  increase  or  decrease 
in  the  overall  caseload,  alteration  of  the  distribution  of  distressed  units  in 
the  overall  caseload,  imposition  of  a distance  offshore  band  for  cases,  adding 
or  deleting  cases  in  a particular  area,  and  alteration  of  the  demand  mix  in  an 
area. 

The  SARSIM  analyst,  in  order  to  present  a realistic  caseload  to  the 
simulator,  may  want  to  either  increase  or  decrease  the  overall  caseload.  This 
is  accomplished  by  specifying  the  percentage  increase  or  decrease  and  then 
this  increase/decrease  is  applied  to  the  number  of  cases  which  are  to  be 
selected  daily.  The  user  may  specify  different  percentages  for  search  or 
nonsearch  and  weekday  or  weekend/hol iday  cases. 

If  desired,  the  analyst  may  specify  the  mix  of  distressed  units, 
this  mix  would  apply  to  the  total  caseload  and  is  imposed  after  the 
i ncrease/decrease  has  been  applied.  The  mix  is  specified  simply  by  listing 
distressed  unit  codes  and  the  percentage  of  that  code  which  is  to  be  selected. 

The  distance  offshore  restriction  is  imposed  after  basic  case 
selection  has  taken  place  and  involves  the  deleting  of  ceases  which  do  not 
satisfy  the  analyst's  distance  offshore  restriction.  Both  an  upper  and  a 
lower  bound  may  be  specified  for  the  distance  offshore  restrictions . 

The  analyst  may  desire  to  add  cases  in  one  area  and  delete  cases  in 
another  area.  For  instance,  if  a new  marina  opens,  cases  may  need  to  be 
added,  and  if  a marina  closes,  cases  may  need  to  be  deleted.  The  addition  of 
cases  is  accomplished  by  having  the  analyst  specify  an  area  and  an 
occurrence-per-day  histogram  for  that  area,  additionally  a distribution  of 
distressed  units  may  also  be  included.  These  cases  are  simply  added  to  those 
already  selected.  The  deletion  of  cases  in  an  area  is  accomplished  by  either 
specifying  a percentage  of  cases  which  are  to  be  retained  in  the  area  or  by 
specifying  a percentage  of  particular  distressed  unit  types  which  will  be 
retained.  Distressed  unit  types  which  are  not  specified  will  not  be  affected. 

The  alteration  of  the  demand  for  service  mix  in  an  area  is 
accomplished  by  specifying  the  demands  to  be  altered  and  their  probability  of 
retention  if  encountered.  The  analyst  might  wish  to  altar  the  demand  mix  if, 
for  instance,  a new  towing  service  opened  in  the  area  and  it  was  expected  that 
the  number  of  "tow"  demands  should  be  reduced. 

Finally,  since  all  case  selection  is  based  on  random  processes,  the 
analyst  is  allowed  to  request  several  sets  of  cases  for  the- period  to  be 
simulated  and  final  selection  of  the  event  files  to  be  used  as  input  to  the 
simulator  would  then  be  from  among  these  several  requested  sets. 
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ELEMENT  KEPT  FOR  REMARKS: 


NUMBER 

CONTENT 

PHASE  2 

ITEM  NUM8ER  IN  CG-397 

I 

Oi strict  number 

★ 

2 

Multi-unit  case  number 

★ 

A. 02 

3 

District  number 

4 

Single-unit  OPFAC  number 

★ 

A. 01 

5 

Unit  case  number 

k 

A. 03 

6 

Record  code 

k 

7 

Record  number 

3 

Unit  name 

9 

Month  notified 

k 

A. 04 

10 

Year  notified 

★ 

A. 04 

11 

Total  number  of  sorties  on  case 

k 

A. 05 

12 

Oay  of  the  month  notified 

k 

3.01 

13 

Hour  of  the  day  notified 

k 

8.01 

14 

Minute  of  hour  notified 

k 

S.01 

15 

Time  from  occurrence  to 

notification 

3.02 

16 

Means  of  initial  CG  notification 

8.03 

17 

Nature  of  distress 

3.04 

18 

Distance  offshore  code 

k 

3.05 

19 

Latitude  in  degrees 

k 

8.06 

20 

Minutes  of  latitude 

k 

3.06 

21 

Longitude  in  degrees 

k 

3.07 

22 

Minutes  of  longitude 

k 

8.07 

23 

Method  of  locating  distressed  unit 

8.Q8 

24 

Severity  of  distress  - personnel 

k 

3.09 

25 

Severity  of  distress  - property 

k 

3.10 

26 

Cause  of  distress 

3.11 

27 

Sea  state 

k 

3.12 

23 

Wind 

k 

B.  13 

29 

'/isibil  ity 

k 

3.14 

30 

Type  of  distressed  unit 

8.15 

31 

Ownership  of  distressed  unit 

8.16 

32 

Usage  of  distressed  unit 

k 

3.17 

33 

Propulsion  of  distressed  unit 

8.13 

34 

Length  of  distressed  unit 

k 

8.19 

35 

Gross  tonnage  distressed  unit 

3.20 

36 

Official/Registration  number 

3.21 

37 

Number  of  lives  lost 

k 

3.22 

38 

Number  of  lives  saved 

k 

B.23 

39 

Number  of  persons  otherwise 

assisted 

■» 

3.24 

FIGURE  2.1.2 

ELEMENTS  OF  A $AR  OATA  3ASE  RECORD 


ELEMENT 

KEPT  FOR 

REMARKS: 

NUMBER 

CONTENT 

PHASE  2 

ITEM 

NUMBER  IN  CG-397 

40 

Value  of  property  assisted 

★ 

B.25 

41 

Day  of  week 

42 

Day/Night 

43 

Type  of  assisting  resource 

C.01) 

These  data 

44 

Oi stance  to  scene  or  search  area 

C.06) 

are  optimized 

45 

Assistance  rendered  to  personnel 

C.08) 

for  this 

46 

Assistance  rendered  to  property 

C.09) 

case 

47 

Type  of  assisting  resource 

* 

C.01 

48 

Assisting  resource  number 

C .02 

49 

Oay  of  the  month  underway 

★ 

C.03 

50 

Hour  of  the  day  underway 

★ 

C .03 

51 

Minute  of  the  hour  underway 

★ 

C.03 

52 

Number  of  remaining  resources  on 

standby 

C .04 

53 

Oay  of  the  month  on  scene 

★ 

C.05 

54 

Hour  of  the  day  on  scene 

★ 

C.05 

55 

Minute  of  the  hour  on  scene 

★ 

C.05 

56 

Oistance  to  scene  or  search  area 

C.06 

57 

Total  time  on  sortie  (hours) 

★ 

C.07 

53 

Total  time  on  sortie  (tenths  of 

hours) 

★ 

C .07 

59 

Assistance  rendered  to  personnel 

★ 

C.08 

60 

Assistance  rendered  to  property 

* 

C.09 

61 

Performance  index 

C.10 

NOTE: 

Please  consult  Reference  3 for  complete  detai 

Is  on  t 

he  items 

mentioned  above. 


FIGURE  2.1.2  (continued) 
ELEMENTS  OF  A SAR  OATA  BASE  RECORO 
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VAR  TABLE  HOW  OBTAINED 


Hour  of  occurrence  T 

Minute  of  hour  T 

Longitude  (radians)  C 

Latitude  (radians)  C 

Sea  state  code  T 

Wind  code  T 

Visibility  code  T 

Severity  (severe  or  routine)  C 

Oi stance  offshore  code  T 

Usage  of  distressed  unit  code  T 

Number  of  lives  lost  T 

Number  of  lives  saved  T 

Number  of  persons  otherwise  assisted  T 

Value  of  property  assisted  T 

Number  of  demand  pairs  C 

(Assistance  rendered  to  personnel  code  T# 

(Assistance  rendered  to  property  code  T# 

(Number  of  miles  traveled  until  sortie  aborted  T# 

Additional  variables  for  search  cases 

(Oay  of  month  notified  T 

(Total  miles  searched  C 


C = Calculated  Variable 
T 3 Transferred  Variable 

# indicates  a variable  which  is  repeated  for  each  set  of  demand  pairs 


FIGURE  2.3.1 

TYPICAL  PHASE  3 CASE  RECORD 
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VAR IA8LE 


HQU  Q8TAINED 


I 


Name  of  event  ("NOSRCH"  - nonsearch;  "ENIGMA"  - search)  C 

Time  of  occurrence  C 

Sea  state  C 

Wind  C 

Visibility  C 

Severity  T 

Longitude  T or  C 

Latitude  T or  C 

Distance  offshore  C 

Usage  of  distressed  unit  T 

Tonnage  of  distressed  unit  C 

Number  of  lives  lost  T 

Number  of  lives  saved  T 

Number  of  persons  otherwise  assisted  T 

Value  of  property  assisted  T 

Number  of  demands  for  service  C 

Name  of  demand  C# 

Service  time  for  the  demand  C# 

Additional  of  variables  for  search  cases 

Total  miles  searched  . T 

Hour  of  occurrence  T 


C = Calculated  Variable 
T = Transferred  Variable 

# indicates  a variable  which  is  repeated  for  each  set  of  demand  pairs 


FIGURE  2.4.1 

TYPICAL  EVENT  FILE  CASE  RECORD 


r 

• 

VARIA8LE 



TA8LE  2.4.1 

COOED  VARIABLES  WHICH  ARE  GIVEN  REAL  VALUES 

COOED  VALUE  REAL  VALUES  IN  CG-397  VALUE  ASSIGNED  BY  SARSIM 

■ 

SEA  STATE 

0 

Calm  (feet) 

0 (feet) 

>! 

1 

1 - 2 

1 - 2 

2 

3 - 4 

3 - 4 

3 

5 - 6 

5 - 6 

4 

7-10 

7 - 10 

5 

11  - 20 

11  - 20 

6 

Greater  than  20 

20  - 50* 

|!j 

8 

Land 

0* 

1 

H 

9 

Unknown 

0 - 50 

WINO 

0 

Calm  (knots) 

0 (knots) 

Li 

1 

0.1  - 10.0 

0.1  - 10.0 

2 

10.1  - 20.0 

10.1  - 20.0 

3 

20.1  - 30.0 

20.1  - 30.0 

| 

4 

30.1  - 40.0 

30.1  - 40.0 

5 

40.1  - 50.0 

40.1  - 50.0 

5 

50.1  - 60.0 

50.1  - 60.0 

1 

7 

60 .1  •*  70.0 

60.1  - 70.0 

8 

Over  70 

70.1  - 100.0* 

9 

Unknown 

0 - 100 

VISI3ILITY 

0 

0 - 1/4  (miles) 

0 - 1/4  (miles) 

L 

1/4  - 1/2 

1/4  - 1/2 

2 

1/2  - 1 

1/2  - 1 

3 

1.1  - 3.0 

1.1  - 3.0 

4' 

3.1  - 5.0 

3.1  - 5.0  s 

5 

5.1  - 10.0 

5.1  - 10.0 

6 

10.1  - 15.0 

10.1  - 15.0 

i 

7 

15.1  - 20.0 

15.1  - 20.0 

* 

8 

Uni imi tad 

20.0* 

9 

Unknown 

0 - 20 

LENGTH 

0 

Other  then  vessel 

0 (feet) 

h 

TONNAGE  (# 

) 1 

Less  than  16  feet 

5 - 15 

2 

116  - 26  (feet) 

16  - 25 

. 

3 

25  - 40 

25  - 40 

4 

40  - 65 

40  - 55 

5 

55  - 100 

55  - 100 

5 

100  - 200 

100  - 200 

7 

200  - 300 

200  - 300 

8 

300 

300  - 1200* 

9 ' 

( 

Unknown 

0 

1 

M 

O 

O 

* Extreme 

values  were  established  by  G-OSR 

* TONNAGE 

= ( LENGTH) 3/64C0 

TABLE  2.4.1  (continued) 

COOED  VARIABLES  WHICH  ARE  GIVEN  REAL  '/ALLIES 


VARIABLE 


COOED  VALUE  REAL  VALUES  IN  CG-397  VALUE  ASSIGNED  3Y  SARSIM 


01 STANCE 
OFFSHORE 


0 

1 

2 

3 

4 

5 

6 
7 
3 
9 


Land 
0 - 3 

3.1  - 10.0 

10.1  - 25.0 

25.1  - 50.0 

50.1  - 100.0 

100.1  - 150.0 

150.1  - 300.0 
300 

Unknown 


0 (miles) 

0 - 3 

3.1  - 10.0 

10.1  - 25.0 

25.1  - 50.0 

50.1  - 100.0 

100.1  - 150.0 

150.1  - 300.0 
300  - 1100* 

0 - 1100 


* Extreme  values  were  established  by  G-OSR 

# TONNAGE  = (LENGTH) 3/6400 
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3.0  THE  SIMULATOR 


3.1  SIMULATOR  INTRODUCTION 

In  terms  of  Queueing  theory,  the  SIMULATOR  is  a mul ti -server , 
priority  discipline  model  with  ill-defined  arrival  time  distributions,  which 
in  effect  simulates  the  SAR  system  by  setting  up  an  appropriate  mathematical 
model  that  relates  the  component  quantities:  Coast  Guard  vehicles  and  service 
facilities.  The  SIMULATOR  is  a computer  model  that  combines  historical  data 
and  event-paced  simulation  for  the  purpose  of  evaluating  and  predicting  the 
behavior  of  these  components.  Having  observed  the  manner  in  which  the  system 
behaves  over  a time  period  under  such  simulated  conditions,  the  system  may  be 
altered  in  an  attempt  at  improvement.  Artificial  system  histories  can  be 
constructed  and  averaged  in  order  to  obtain  estimates  of  system  performance 
and  suggestions  for  possible  improvements  to  the  SAR  system. 

The  OEM  output  provides  the  stimulus  necessary  to  activate  the 
simulator's  response  mechanisms.  This  output  is  in  the  form  of  reported 
historical  Coast  Guard  Cases  as  outlined  in  Section  2.0.  The  reported  Case's 
parameters  include  information  about  the  time  of  occurrence,  the  location,  the 
environment,  and  reported  demands  for  service.  Responding  resource  data  for  a 
sortie  is  not  included  as  input  to  the  SIMULATOR.  This  is  because  forcing  the 
same  resources  and/or  stations  to  respond  to  a call  for  service  that  were 
assigned  to  the  Case  historically  would  defeat  the  purpose  of  exercising  the 
model  which  is  to  be  able  to  allocate  different  resources  and/or  stations  in 
order  to  ascertain  the  consequences  that  this  has  on  SAR  effectiveness.  Thus 
the  SIMULATOR'S  responses  are  independent  of  historical  sortie  respondence. 

As  the  Cases  are  presented  to  the  SIMULATOR,  the  time  of 
notification  on  the  Case  Record  produces  a time  series  which  is  assumed  to  be 
a true  realization  from  the  collection  of  all  possible  sample  functions  which 
the  random  phenomena  might  have  produced  in  the  real  SAR  world.  A 
multidimensional  vector  of  Casa  attributes  is  associated  with  each  of  these 
times  of  notifications.  The  vector  contains  parameters  character! zing  the 
nature  of  the  distress  and  the  environment. 

• 

Only  two  variables  reflect  the  environment;  visibility,  (in  miles), 
and  sea  state,  (in  feet).  Although  these  variables  vary  as  each  Case  enters 
the  SIMULATOR,  they  remain  constant  during  the  time  that  the  Case  is  being 
processed . 


The  parameters  describing  the  nature  of  the  distress  are  limited  to 
the  demands  for  service  and  the  tonnage  of  the  distressed  unit  or  client.  The 
tonnage  is  used  for  selecting  an  able  resource  or  responder  to  the  client. 

The  type  of  client  has  no  affect  on  the  response  of  the  system. 

The  service  requirements  or  demands  are  assumed  known  at  the  time  of 
notification  if  the  Casa  is  not  a search.  The  resource  that  is  ordered  to- 
service  the  client  is  assigned  demand(s)  prior  to  deoarting’its  station. 
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The  priority  of  the  Case  has  the  greatest  effect  on  the  response 
mechanisms  of  the  SIMULATOR.  The  SIMULATOR  reacts  to  a binary  condition  of 
either  severe  or  routine.  Analyst  controlled  selection  policies  for  both 
stations  and  responders  elicit  a variety  of  alterations  in  the  way  in  which 
the  Cases  are  handled  by  the  system.  Although  the  parameter  that  initially 
contains  the  priority's  status  does  not  vary  during  the  time  that  the  case  is 
being  processed,  the  technique  of  queueing  Cases  FIFO  produces  an  increasing 
priority  queue  discipline! 

The  reported  positions  of  the  clientage  are  assumed  fixed  th>  <ghout 
the  duration  of  Case  processing.  This  location  greatly  influences  the 
timeliness  of  providing  the  services  and  the  manner  in  which  resources  are 
selected  because  of  restrictions  imposed  by  fuel  limitations,  distance 
limitations,  and  the  amount  of  time  that  a crew  can  remain  aboard  a resource. 

The  SIMULATOR  responds  to  the  above  stimuli  by  determining  the 
primary  station  that  is  to  receive  the  distress  call.  The  nearest  station  to 
the  client's  reported  position  is  considered  to  be  the  primary  station. 

Each  station  is  assigned  a set  of  resources  which  can  vary  by  type 
thereby  yielding  dissimilar  capabilities.  Since  the  resources  have  physical 
traits  that  limit  their  operation  in  certain  kinds  of  weather,  distance 
constraints,  maintenance  downtimes,  crew  unavailability  and  inability  to 
service  certain  demand  types,  resources  affiliated  with  a station  may  or  may 
not  be  able  to  sortie  to  the  Casa.  In  order  to  effectuate  a response,  the 
SIMULATOR  may  need  to  solicit  other  nearby  stations.  The  aforesaid  selection 
policies  will  also  have  an  impact  on  the  actions  that  follow  the  entrance  of  a 
Case  into  the  SIMULATOR. 

Resources  are  central  to  the  model,  as  they  provide  the  system 
dynamics  through  the  response  given  to  calls  for  service,  i.e.,  without 
resources,  no  activity  would  transpire  in  the  SIMULATOR. 

'when  a resource  is  sent  to  service  a client,  the  average  speed  of 
the  resource  is  most  critical  in  that  it  directly  affects  the  amount  of  time 
that  a client  will  wait  :or  service.  Other  parameters  such  as  fuel 
consumption  rate,  fuel  capacity  and  cr'ew  endurance  play  an  important  role  in 
servicabi 1 ity.  For  example,  a responder  searching  for  a lost  craft  may  be 
forced  to  leave  the  search  area  prematurely  due  to  fuel  shortage  or  rules 
prohibiting  the  craw  from  remaining  on  duty  past  a given  length  of  time.  In 
addition,  the  cost/operating  hour  for  a resource  can  be  a factor  in  selecting 
a resource  for  a Case. 

Many  events  are  generated  throughout  a particular  exercise.  As 
these  events  cause  interactions  within  the  SIMULATOR  many  outcomes  are 
possible  for  soecific  items  of  interest.  In  order  to  introduce  the  way  the 
system  behaves  when  supplied  with  the  Case  stimulus  a few  examples  are  given 
in  Table  3.1.1,  SIMULATOR  3ehavior. 

Condition  A is  an  examole  of  a very  simple  Case  in  which  the  client 
needs  a tow.  A station  is  found  that  has  an  available  qualified  resource, 
resource  #1.  The  Coast  Guard  was  notified  of  the  incident  at  0800  hours. 
During  the  period  from  0800  to  0330,  the  crew  and  resource  are  readied, 
commencing  the  journey  to  the  location  of  the  distressed  unit  at  0830  hours. 
The  trip  takes  45  minutes  so  the  rescue  vehicle  arrives  along  side  the 
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disabled  craft  at  0915  hours.  Hooking  up  the  tow  takes  15  minutes.  The 
resource  begins  towing  the  client  to  the  nearest  dock  at  0930  hours.  Finally, 
the  resource  releases  the  unit  at  another  station  at  1000  hours  arriving  back 
at  its  home  station  30  minutes  later.  The  last  column  in  the  table  gives  a 
waiting  time  of  1.25  hours,  which  is  the  time  from  notification  until  the 
resource  arrived  on  scene. 


I 
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Example  Condition  S introduces  the  affect  of  downtime  on  the 
SIMULATOR.  The  Case  is  identical  to  the  above  except  that  a delay  of  30 
minutes  is  added  to  the  departure  time  of  the  resource.  This  causes  the 
waiting  time  to  increase  to  1.75  hours.  The  delay  may  have  been  caused  oy 
maintenance  or  perhaps  refueling  the  resource  after  it  had  just  returned  from 
a previous  Case.  It  is  possible  that  another  resource  may  respond  to  the  Case 
thereby  resulting  in  the  delayed  resource  not  being  selected  to  respond. 

More  complex  activity  takes  place  in  example  Condition  C.  Case 
number  2 enters  the  system  at  0845  hours  while  resource  #1  was  enroute  to  Case 
number  1.  Case  number  2 ' s priority  is  "severe"  because  there  is  a fire  on  the 
craft.  The  distressed  craft  is  within  range  of  resource  #1.  Since  case 
number  1 is  "routine",  it  is  preempted  and  queued  at  0350  hours,  i.e.,  the 
time  that  resource  #1  diverts  to  Case  number  2.  Resource  #1  arrives  along 
side  the  burning  vessel  at  0920  hours  and  starts  fighting  the  fire. 

In  the  meantime,  another  resource,  #2,  completes  service  on  seme 
other  nearby  Case,  (not  shown  in  table),  and  heads  for  Case  number  1 at  0902 
hours.  It  arrives  along  side  the  disabled  craft  at  0930  hours,  hooks  up  the 
client  and  at  0945  hours  starts  to  tow  the  vessel  to  the  nearest  facility. 

After  the  fire  is  put  out  on  Case  number  2,  resource  #1  heads  back 
to  its  home  station  at  1045  hours.  If  resource  #2  hadn't  responded  to  Case 
number  1,  resource  #1  would  have  gone  back  to  the  original  distress  and  towed 
the  disabled  craft  to  the  nearest  dock.  This  would  have  resulted  in  a much 
longer  waiting  time  for  Case  number  1. 

Example  Conditions  0 and  E are  searches.  In  example  Condition  0 a 
resource  #1  arrives  in  the  search  area  at  1400  hours  and  spends  3 hours 
searching  for  the  lost  craft.  The  resource  returns  home  at  1730  hours  without  ' < 

finding  the  distressed  unit  because  it  was  not  able  to  operate  at  night. 

Example  Condition  E demonstrates  the  circumstance  where  another 
resource,  #2,  is  sent  on  the  same  search  case.  After  searching  for  about  an 
hour,  the  resource  becomes  low  on  fuel  at  1500  hours.  The  resource  leaves  the 
area  and  transits  to  a nearby  refueling  site  arriving  there  at  1520  hours  to 
replenish  its  supply.  This  operation  takas  35  minutes.  At  the  end  of  this 
time  the  resource  returns  to  the  search  area  at  1515  hours  and  stays  for  2 
hours  and  15  minutes  to  complete  the  search.  When  the  search  is  finished, 
additional  service  may  or  may  not  be  necessary.  If  it  can't  help,  resource  #2 
arrives  home  at  1901  hours. 

A special  type  of  resource  called  a patrol  is  allowed  to  roam  about 
a specified  area  and  may  be  allowed  to  participate  in  servicing  a Case  or 
engage  in  search  exercises.  In  example  Condition  C,  resource  ?2  could  very 
well  have  been  a patrol  type  resource. 
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The  analyst  should  study  the  above  examdes  and  visualize  the 
multitude  of  activities  that  responders  might  well  be  involved  in  both  the 
real  world  and  the  SIMULATOR. 

After  the  SIMULATOR  has  processed  all  the  events  within  the  desired 
time  frame,  a report  is  generated  with  a variety  of  statistics  such  as;  the 
number  of  queued  cases,  crew  and  resource  utilizations,  number  of  sorties  by 
station  and  resource  type,  average  transit  times,  average  waiting  times, 
frequency  distributions  of  variables  of  interest,  etc.  (See  section  3.5) 

In  addition,  data  concerning  the  disposition  of  each  Case  are 
optionally  output  to  a file  which  is  accessible  through  the  use  of  a data 
retrieval  system.  In  this  way,  the  analyst  can  obtain  snapshots  of  certain 
behavior  after  the  simulation  has  run  its  course  to  gain  further  insight  into 
the  operations  being  studied.  The  analyst  can  also  tailor  his  reports  to  a 
specific  problem.  (See  section  4.0) 


3.2  SIMULATOR  Input 

3.2.1  Preparation  of  Input  for  the  SIMULATOR 

The  SIMULATOR  requires  two  types  of  input.  The  first  type 
consists  of  the  event  scenarios  that  were  generated  as  output  of  the 
PREPROCESSOR.  The  user  specifies  two  case  files  for  input  into  the  SIMULATOR, 
one  file  containing  search  cases  and  one  file  containing  nonsearch  cases.  See 
Reference  13. 

The  second  type  of  input  is  the  user  specified  data,  which 
are  prepared  on  computer  cards.  Table  3.2.1  describes  both  those  data 
elements  that  are  required  as  input  by  the  user  and  those  that  are  available 
as  user  options.  See  Reference  10. 

The  user  control  inputs  correspond!' ng  to  Table  3.2.1  are 

discussed  below: 

(1)  Debugging  Flags  (Elements  1-5)  - Although  the  user  will 
probably  not  be  concerned  with  using  the  debugging  tools  that  are 
provided  for  in  the  SIMULATOR,  he  must  still  provide  the  program  with  an 
input  indicating  whether  or  not  he  desires  to  have  the  event  trace 
outputs  activated.  Should  the  user  happen  to  desire  trace  output,  he 
must  also  specify  those  events  for  which  he  desires  the  output  (e.g., 
arrive  scene,  arrive  home,  or  end  search).  Additionally,  the  user  is 
required  to  specify  whether  or  not  he  desires  particular  trace  types, 
where  the  types  include  search,  nonsearch,  and  underway  traces, 
regardless  of  his  decision  for  the  event  traces.  Set  elements  1-5  to  1 
and  elements  41-42  to  0.0. 

(2)  Simulation  Time  Oata  (Elements  5-10)  - The  user  is 
required  to  specify  the  number  of  days  he  wishes  to  simulate,  the  month, 
day,  and  year  of  the  start  data  and  the  corresponding  Julian  data.  The 
start  data  must  be  on  Monday. 


(3)  Output  Options  (Elements  11-12)  - The  user  has  the 
ability  to  specify  whether  or  not  he  desires  the  printed  output  reports 
which  are  provided  at  the  end  of  the  simulation  run.  He  also  has  the 
option  of  choosing  to  collect  and  record  the  detailed  case  data  for 
subsequent  postprocessing. 

(4)  Resource  Selection  Policies  for  Routine  Cases  (Elements 
13-14)  - Two  policies  must  be  specified  by  the  user  so  that  the  SIMULATOR 
can  determine  the  resource  selection  for  routine  cases.  The  two  policies 
are  an  economic  and  the  station  selection  policy,  where  the  priority 
policy  considered  by  the  SIMULATOR  is  the  station  selection  policy.  That 
is,  the  SIMULATOR  first  determines  the  desired  station  and/or  stations 
from  where  a resource  may  be  selected  according  to  the  specified  policy 
and  then  selects  the  resource  from  the  selected  station(s)  based  on  the 
chosen  economic  policy.  The  station  selection  policy  affords  the  user 
with  four  options,  including  selection  from  the  nearest  station  only,  the 
nearest  station  within  the  nearest  group  only,  the  nearest  station  and 
its  adjacent  station,  and  the  nearest  station  with  an  available 
resource.  The  economic  policy  also  affords  the  user  with  four  options. 
That  is,  once  the  possible  station(s)  has  (have)  been  determined,  the 
SIMULATOR  selects  resources  based  on  a minimum  weighted  ranking,  minimum 
costs,  fastest  to  arrive  on  scene,  or  al ternati vely  with  no  consideration 
given  to  speed  or  cost. 

(5)  Resource  Selection  Policies  For  Severe  Cases  (Elements 
15-16)  - Two  policies  must  be  specified  for  severe  cases.  These  policies 
include  the  station  policy  and  the  interruption  or  preemption  policy. 

The  first  policy  affords  the  user  with  two  choices;  resource  selection  is 
made  either  from  among  the  stations  within  the  nearest  group  or 
alternatively  from  any  station  that  has  an  available  resource.  The 
second  policy  specifies  the  priority  for  resource  selection  when 
interruptions  of  underways  may  also  be  considered.  This  policy  allows 
the  user  four  options.  The  first  option  specifies  that  interruptions  are 
not  allowed,  i.e.,  resources  that  are  enroute  to  a case,  servicing, 
returning  home,  or  patrolling  cannot  be  considered  for  selection.  The 
second  option  specifies  that  resources  will  first  be  selected  from 
underways  and  then,  if  necessary,  from  resources  located  at  facilities. 
The  third  option  specifies  that  the  resources  will  be  selected  from  those 
stationed  at  facilities  and  then,  if  necessary,  from  those  that  are 
underway.  The  last  option  allows  for  resource  selection  from  either 
facility  resources  or  underways  with  no  regard  for  a specified  order  in 
the  selection. 

(5)  Crew  Change  Policy  (Elements  17,  32,  33,  105  and  106)  - 
I The  actual  number  of  personnel  making  up  the  crew  is  immaterial  to  the 

SIMULATOR.  Furthermore,  a crew  is  not  assigned  to  any  particular  boat  or 
aircraft.  The  analyst  can  control  the  shifts  that  crews  are  available  in 
the  following  ways: 

| 

1.  Ready  Crews:  This  type  of  crew  is  available  throughout  the 
exercise.  Although,  its  selection  can  be  refined  by  having  it  available 
only  on  weekends  or  weekdays,  it  will  be  ready  at  any  hour  during  a day. 


. 


2.  Standby  Crews:  These  crews  are  available  throughout  the  simulation 
but  they  have  a pre-set  time  delay  which  effects  the  departure  time  of 
the  resource.  The  weekday-weekend  refinements  as  described  above  for  the 
ready  crews  also  hold  for  the  standby  crews.  However,  the  SIMULATOR  will 
always  try  to  assign  ready  crews  before  standby  crews.  Also,  if  a 
resource  with  a standby  craw  has  not  departed  its  station  and  another 
resource  becomes  immediately  available  to  perform  all  the  demands  that 
are  assigned  to  the  standby  crew  resource,  the  standby  crew  will  be 
recalled  and  the  other  resource  will  take  over  the  Case. 

3.  Crew  Changes:  The  user  is  afforded  with  two  methods  for  specifying 
crew  changes.  That  is,  a crew  change  may  be  effected  district  wide  or 
for  each  station.  However,  the  user  must  select  one  method  or  the  other 
at  the  beginning  of  a run. 

In  the  former  instance,  the  capability  to  evaluate  the 
effects  of  varying  shore  station  readiness  posture  is  provided  within  a 
24  hour  period.  To  accomplish  this  the  analyst  can  input  two  times, 
i.e.,  0800  and  1600.  These  would  be  the  times  within  a 24  hour  period 
when  any  standby  crews  would  change  to  ready  crews  and  then  back  to 
standby.  The  weekday-weekend  limits  will  still  override  this  policy.  In 
the  latter  instance,  the  analyst  can  preassign  the  time  the  ready  crew  is 
to  go  on  and  off  duty  during  a shift. 

(7)  Accompanying  Resource  Policy  (Elements  19-20,  28)  - The 
user  also  has  the  option  of  selecting  a forced  accompanying  resource 

pol icy  ’for  both  search  and  nonsearch  cases.  When  the  user  opts  for  this 
forced  accompaniment  at  least  one  surface  and  one  air  resource  will  be 
sent  to  the  case.  If  there  is  no  actual  demand  for  the  resource  to 
service,  a dummy  standby  demand  is  created. 

HH-52A  Policy:  A special  forced  accompaniment  is  also 
included  in  the  SIMULATOR  in  which  the  HH-52A  resource  types  will  never 
be  selected  as  responders  for  Cases  more  than  25  miles  off  shore  without 
accompanying  resource  types.  This  feature  is  "hard  wired"  in  the 
SIMULATOR,  i.e.,  the  analyst  cannot  control  this  policy. 

(8)  Search  Pol  icy  (Element  13)  - The  user  has  the  option  of 
selecting  two  search  policies.  The  first  policy  is  one  where  the  user 
specifies  the  preferred  and  alternate  resources  for  routine  and  severe 
cases  separately  (elements  77-33).  This  option  also  requires  the  user  to 
specify  which  resources  are  preferred  to  go  within  and  beyond  a 
particular  distance.  This  method  is  referred  to  as  the  SEARCH  TABLE 
policy.  The  second  policy  allows  for  resource  selection  from  available 
resources  and  tries  to  send  the  same  number  of  resources  that 
participated  historically.  It  is  anticipated  that  since  the  first  method 
could  impose  some  rather  strict  limitations  that  the  second  method  might 
be  the  more  desirable. 

(9)  Random  Flags  (Elements  21-23)  - The  users  also  has  the 
option  of  chosing  either  random  or  constant  times  for  the  service  time, 
dispatch  time,  and  standby  time. 
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(10)  Tow-Handoff  Oata  (Elements  25-27)  - The  user  must 
specify  three  parameters  for  tow-handoffs . They  are  the  minimum  distance 
at  which  a resource  requiring  a two-handoff  can  get  to  the  shoreline,  the 
time  it  requires  for  the  tow-hookup,  and  the  maximum  time  that  a resource 
can  wait  for  a tow-handoff. 

(11)  Standby  Service  Time  (Element  28)  - If  the  user  has 
opted  for  the  forced  accompaniment  policy  he  must  specify  the  time  that 
he  would  like  the  resource  to  standby,  should  this  dummy  demand  be 
necessitated. 

(12)  Crew  Ready  Time  (Element  29)  - The  user  must  input 
either  a constant  or  the  mean  time  for  readying  a standby  crew  depending 
on  his  previous  selection. 

(13)  Fuel inq  Times  (Elements  30-31)  - Two  times  must  be 
entered  for  resource  refueling,  i.e.,  the  time  for  resources  refueling  at 
any  refueling  station  and  the  time  for  home  station  refueling  by  any 
resource . 


(14)  Oi strictwide  Crew  Shift  (Elements  32-33)  - Should  the 
user  select  this  method  for  crew  shifts,  he  must  provide  two  other 
inputs.  They  are  the  time  which  a standby  crew  shifts  to  ready  status 
and  the  time  at  which  the  crew  shifts  back  to  standby  status. 

(15)  Failure  Criteria  Times  (Elements  34-36)  - The  user  must 
specify  three  different  times  that  are  used  by  the  simulation  program  to 
declare  failures.  The  first  of  these  failures  is  a response  failure, 
where  the  elapsed  time  from  the  initial'  notification  of  the  distressed  to 
the  arrival  of  the  first  responder  exceeds  the  user  specified  time.  The 
second  is  a transit  failure,  where  the  first  responder  fails  to  arrive 
from  its  dispatched  point  within  the  user  specified  time.  The  third  is  a 
locate  failure,  which  occurs  when  the  elapsed  time  from  the  arrival  of 
the  first  responder  to  the  designated  search  area  until  the  search  is 
completed  exceeds  the  user  specified  time. 

(16)  Event  Flags  and  Times  (Elements  37-40)  - The  user  has 
the  option  of  activating  an  event  which  accumulates  statistics  at 
specified  intervals  of  time.  If  the  user  desires  the  event,  he  must 
specify  a time  interval  and  if  he  does  not,  he  merely  has  to  input  a 
zero.  Since  the  actual  programming  of  the  event  code  is  done  by  the 
analyst  the  user  is  urged  to  suppress  the  triggering  of  this  event.  The 
user  also  has  the  option  of  specifying  data  for  the  activation  of  another 
event,  READI,  where  this  event  performs  a somewhat  more  meaningful 
function.  The  user  first  must  indicate  whether  or  not  he  is  specifying 
the  time(s)  for  triggering  this  event.  He  then  must  specify  the  number 
of  times  as  well  as  the  actual  times  that  he  is  providing  as  input.  This 
event  is  used  for  several  activities,  the  primary  one  being  to  check  to 
determine  if  waiting  distressed  units  can  be  taken  out. of  queue  because 
of  new  availability  of  resources  at  the  time  provided. 

(17)  Snapshot  Debugging  (Elements  41-42)  - An  option  is 
available  for  specifying  beginning  and  ending  times  for  which  the  traces 
(Elements  1-5)  will  be  activated.  However,  this  option  is  generally  used 
by  the  programmer  and  the  user  can  suppress  use  of  the  debugging  tool  by 
specifying  zero  times. 
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(18)  Time  Zone  (Element  43)  - The  user  must  specify  the  time 
zone  in  which  the  district  is  located.  The  time  zone  is  from  Greenwich 
and  is  necessary  for  the  sunrise  and  sunset  calculations. 

(19)  Input  Printout  Flag  (Element  44)  - The  user  has  the 
option  of  having  his  input  data  printed  out.  Selecting  this  option  is 
generally  a good  idea  in  that  it  provides  the  user  with  a means  for 
examining  the  data  and  detecting  possible  errors  that  were  made  in  the 
data  preparation. 

(20)  Patrol  Option  (Element  45)  - The  user  must  specify 
whether  he  desires  to  include  patrols  in  the  simulation. 

(21)  Sunrise  and  Sunset  (Elements  46-48)  - The  user  has  the 
option  of  specifying  constant  times  for  the  sunrise  and  sunset  or 
allowing  the  program  to  do  the  calculation.  If  he  choses  constant  times, 
he  must  specify  the  desired  times  of  day  for  these  activities. 

(22)  Figure  of  Merit  (Elements  127-134)  - The  user  must 
input  eight  parameter  values  used  in  calculating  the  figure  of  merit  for 
the  exercise.  The  user  is  referred  to  Reference  10  for  a discussion  of 
this  calculation. 

(23)  Oi strict  Numbers  (Elements  135-137)  - The  user  must 
specify  the  district  and/or. area  numbers  that  are  to  be  simulated.  There 
is  a required  format,  however,  in  this  case  and  it  is  A 4 left  justified. 

(24)  Comments  (Elements  139-141)  - The  user  may  supply  three 
cards  of  comments  describing  the  simulation  run.  These  three  comments 
will  appear  on  the  printed  summary. 

The  remaining  data  can  be  divided  into  six  categories,  the 
resource  characteristics,  the  search  resource  inputs,  the  resource  allocation 
data,  the  patrol  data,  delay,  and  demand  data.  The  description  of  these  data 
is  given  below. 


(1)  Resource  Characteristics  (Elements  49-75)  - The  user 
has  the  ability  to  specify  the  operational  characteristics  of  the 
resources.  In  order  to  be  able  to  do  this,  he  must  specify  both  the 
number  of  resource  categories  for  which  the  characteristics  are  specified 
and  the  number  of  different  resource  types  that  are  included  in  the 
data.  The  type  characteristics  that  can  be  specified  include  a name  or 
other  identifier  and  hourly  operating  costs.  Operational  restrictions 
such  as  maximum  tonnage  that  can  be  towed,  maximum  allowable  seastate, 
minimum  visibility  and  the  minimum  time  to  be  on  scene  are  user  inputs. 
The  user  can  also  specify  whether  a particular  type  can  operate  in  day 
and/or  night  conditions  along  with  its  refueling  capabilities.  The 
hourly  fuel  consumption  rata  as  well  as  the  maximum  fuel  capacity  must  be 
specified  for  the  resource  type.  Other  operational  characteristics  which 
are  specified  include  the  maximum  crew  endurance,  the  maximum  allowable 
distance  offshore,  and  the  maximum  allowable  distance  from  homeport.  The 
user  may  also  specify  demands  which  cannot  be  performed  by  a resource 
type  by  indicating  the  number  and  name  of  the  demands.  The  resource 
category  (e.g.,  boat,  cutter,  fixed  wing  aircraft)  must  be  given.  There 
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is  a capability  for  specifying  five  speeds  for  each  resource  type.  These 
speeds  include  a normal  operating  speed  and  both  a maximum  towing  and 
non-towing  speed  for  saastates  less  than  or  equal  to  five  feet  and  for 
seastates  that  are  greater  than  five  feet.  The  user  may  also  specify  a 
search-eff ecti veness  coefficient  which  corresponds  directly  to  the 
resource’s  ability  to  complete  its  search. 

(2)  Search  Resources  (Elements  77-83)  - Should  the  user 
choose  to  specify  with  the  search  resources  rather  than  have  the  program 
select  them,  he  must  specify  a SEARCH  TABLE  with  both  the  number  of  the 
preferred  and  the  alternate  resources  along  with  the  type  designator  and 
a search  environment  code.  This  environment  code  specifies  the  type  of 
cases  (routine  or  severe)  that  the  resource  can  service  and  its  distance 
offshore  capabilities.  If  the  resource  is  an  alternate,  the  user  must 
also  specify  the  rank  of  the  alternate,  which  is  used  in  determining  the 
resource  assignments  when  the  preferred  are  unavailable. 

(3)  Resource  Allocation  Data  (Elements  84-106)  - The  intent 
of  these  data  is  tc  define  the  groups  and  stations  and  the  resources 
provided  at  each.  The  user  must  first  specify  the  total  number  of 
groups.  Then  for  each  group,  he  must  specify  a designator  number  and  the 
latitude  and  longitude  of  the  centroid  of  the  group  along  with  the  number 
of  stations  in  the  group.  For  each  station,  a name,  type,  and  latitude 
and  longitude  must  be  specified.  The  user  then  specifies  the  number  of 
resources , the  type  name,  a reliability  parameter  indicating  the 
probability  that  the  type  is  capable  of  getting  underway  when  it  is 
needed,  and  an  index  which  indicates  its  dispatch  delay.  The  total 
number  of  crews  is  specified  for  each  station.  For  each  crew,  the  status 
( i . s . , weekday  and/or  weekend  availability  and  ready  or  standby  status) 
must  be  specified.  3eginning  and  ending  shift  times  need  only  be 
specified  if  the  user  has  selected  the  station  by  station  method  of  crew 
shifts . 


(4)  Patrol  Data  (Elements  107-120)  - Patrol  activity  cycles 
are  independent  of  normal  program  activity  cycles.  This  independence  is 
accomplished  through  the  use  of  a special  entity  which  is  used  to  store 
space-time  information.  This  information  is  supplied  to  the  program  if 
the  patrol  is  called  upon  to  service  a Case. 

The  user  can  control  the  activity  cycles  of  the  patrol  by 
the  manner  in  which  he  creates  the  entity  and  sets  the  attributes  of  the 
entity.  In  order  for  the  user  to  understand  how  to  set  up  the  patrols  he 
must  be  aware  of  the  events  from  the  time  that  the  patrol  comes  into 
existence,  or  is  born,  until  it  goes  out  of  existence,  or  dies.  During 
this  process  the  patrol  becomes  active  either  at  a home  station  or  at  a 
patrol  area,  transits  to  an  area,  remains  in  its  assigned  area  for  a 
period  of  time  and  returns  to  its  original  location  where  it  goes  cut  of 
existence.  These  cycles  are  accomplished  through  the  use  of  four  event 
notices  which  have  as  an  attribute  the  identification  number  of  the 
entity.  They  are: 

INPATR:  This  event  when  triggered  brings  the  patrol  in  to 

existence . 

ACTPAT:  This  event  is  triggered  when  a patrol  arrives  at  the 

centroid  of  the  patrol  area. 
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RTNPAT: 

TERMPA: 


This  event  is  triggered  when  the  patrol  leaves  the  patrol 

area. 

This  event  is  triggered  when  a patrol  arrives  at  its  home 
station . 


The  user  will  be  able  to  schedule  the  events  INPATR  and 
RTNPAT  and  by  setting  the  attributes  appropri ately  will  be  aole  to 
control  the  other  two  events,  ACTPAT  and  TERMPA,  as  the  simulation 
proceeds.  The  event  INPATR  MUST  be  scheduled  for  each  patrol  in  the 
input  parameters,  i.e.,  the  user  must  define  the  existence  of  the  patrol. 


Many  combinations  for  the  activity  cycles  are  possible  but 
the  following  four  modes  are  suggested  and  are  the  only  ones  the  user 
should  set  up: 


MODE  1:  Patrol  comes  into  existence  at  its  home  station,  transits 
to  a specified  area,  stays  in  the  area  for  a specified  time  and  then 
transits  back  to  the  home  station  for  termination. 


MODE  2:  The  patrol  comes  into  existence  in  the  area  and  after  a 
given  period  of  time,  which  could  be  the  length  of  the  simulation. 


it  terminates. 


MODE  3:  The  patrol  comes  into  existence  in  the  area,  stays  there 
for  a period  of  time  and  then  transits  back  to  a home  station  and 
terminates . 


MODE  4:  Same  as  (a)  above  except  occurring  periodical ly. 


The  above  combinations  are  accomplished  by  the  user  by  the 
order  in  which  the  entities  are  created  and  by  the  values  that  the 
attributes  of  the  entity  are  set  to  as  described  below: 


below. ) 


(Refer  to  Table  3.2.1  for  a description  of  the  attributes 


MODE  1: 


This  mode  will  require  two  Patrol  entities  created  with  the 
same  unique  name.  The  first  entity  created  will  have  one 
attribute  set  to  "INPATR"  and  another  attribute  set  to  the  time 
that  the  user  wishes  this  patrol  to  come  into  existence.  Total 
time  on  patrol  must  be  sat  to  a value  greater  ..nan  the  time 
that  the  exercise  is  to  end,  i.e.,  a very  large  value.  The 
second  entity  will  have  one  attribute  sat  to  "RTNPAT"  and  the 
other  set  to  the  time  in  hours  that  the  user  wishes  the  oatrol 
to  return  to  station.  Note:  The  user  must  be  aware  that  the 
program  will  calculate  the  time  that  the  patrol  is  to  arrive  at 
the  scene  based  on  the  coordinates  given  by  the  latitude  and 


longitude  of  the  patrol  area  and  the  station,  so  he  must  -igure 


this  time  into  the  time  that  he  wishes  the  patrol  to  begin  its 
return.  Another  variation  of  this  mode  is  to  let  the  program 
schedule  the  patrol's  return  to  station.  This  is  accomplished 
by  not  including  the  second  entity  and  setting  various  flags. 
The  user  can  continue  this  process  fcr  more  than  one  cycle  if 
he  is  very  careful  not  to  let  the  return  times  overlap,  i.e., 
make 
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sure  the  next  INPATS  event  is  scheduled  to  occur  after  the 
patrol  returns  to  station  and  is  terminated. 
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As  is  always  the  case,  the  patrol  must  be  initially  created 
with  an  entity  set  to  "INPATR".  Another  entity  is  required 
with  an  attribute  set  to  "RTMPAT".  Again,  as  in  MOOE  I,  the 
total  time  on  patrol  in  the  first  entity  must  be  set  to  a very 
large  value  greater  than  the  simulation  exercise  termination. 

Two  entities  are  required  with  the  first  set  to  “INPATR"  and 
the  second  set  to  "RTNPAT".  The  control  flags  are  set  so  that 
the  time  to  leave  the  patrol  area  will  be  calculated.  In  this 
case  the  second  patrol  entity  record  is  not  required  and  the 
program  will  use  the  total  time  on  patrol  to  schedule  the  event 
“RTNPAT" . 

For  this  mode  we  only  need  the  initial  entity  record  with  an- 
attribute  equal  to  “INPATR".  Sy  setting  various  control  flags, 
the  program  will  evaluate  the  next  time  to  go  on  patrol  and  to 
schedule  the  next  "INPATR"  event.  Again  the  user  must  be  aware 
that  the  program  will  calculate  the  transit  times  based  on  the 
position  attributes  of  the  patrol  and  must  account  for  these 
times  if  he  wants  the  timing  to  be  correct. 

The  user  must  include  an  entity  with  the  same  unique  name 
as  the  patrol  in  the  resource  class  tables,  i.e.,  the  capabilities  and 
limitations  must  be  defined. 

The  patrol  statistics  are  gathered  separately  from  the 
normal  resources  so  a special  group  with  number  7777  must  be  created  and 
filled  with  stations  and  resources  similarily  as  with  normal  processing 
except  that  the  program  will  not  attempt  to  select  any  of  these 
resources . The  fictitious  stations  are  only  used  for  collecting 
statistics.  A resource  with  the  same  unique  name  as  the  patrol  must  be 
assigned  to  the  patrol's  home  station  which  also  must  have  the  same  name 
as  the  patrol's  home  station.  All  station  names  must  be  unique,  i.e., 
there  must  be  as  many  stations  in  GROUP  7777  as  there  are  patrols. 

The  user  may  collocate  a patrol's  heme  station  with  any 
other  station.  The  patrol's  home  station  may  not  have  the  same  name  as  a 
station  in  a normal  group.  In  this  way  the  patrol  can  be  sent  from  his 
home  station  but  not  in  the  same  way  as  is  done  in  normal  processing. 

(5)  Delay  Oata  (Elements  121-122)  - The  user  must  enter 
delay  times  for  readying  a resource,  i.e.,  dispatch  delays,  he  must 
specify  the  number  of  delay  times  that  he  wants  to  enter.  If  he  does  not 
want  any  delays,  he  should  use  zero. 

(5)  Demand  Data  (Elements  123-125)  - The  user  must  specify 
the  number  of  demands  that  can  be  serviced,  name  each  demand,  and  give  an 
accompanying  rank  indicating  the  resource's  order  for  performance  of  each 
demand.  Additionally,  if  the  user  has  selected  the  random  service  time 
option,  he  must  accompany  each  demand  with  a mean  service  time. 


MOOE  2: 


MOOE  3: 


MOOE  4. 
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3.2.2  Output  of  the  SIMULATOR  User  Input 


The  output  of  the  SIMULATOR  is  of  several  types,  including  a 
printed  echo  back  of  the  input  data,  printed  trace  data,  printed  summary  data, 
and  detailed  data  which  is  written  to  a file  for  subsequent  postprocessing. 

The  printed  echo  back  of  the  input  is  a user  option.  The  printed  summary  data 
and  the  detailed  data  are  also  user  options  and  are  described  in  Section  3.5. 
and  4.0.  A discussion  of  the  output  echoed  back  is  given  below. 

a.  Resource  Table.  This  table  lists  the  resource 
types  which  are  available  for  servicing  the  caseload.  It  also  echos  back  the 
characteristic  data  that  the  user  initially  provided.  The  operational 
capabilities  include  the  towing  limitations,  the  maximum  seastate  and  the 
minimum  visibility  for  operations,  the  crew  endurance,  and  the  maximum 
distance  the  resource  can  travel  from  its  homeport  to  the  scene.  The  economic 
characteri sties  include  the  fuel  consumption  rate,  total  fuel  capacity,  and 
the  hourly  operating  costs.  The  night  operations  code,  minimum  allowable  time 
an  scene,  and  distance  offshore  limitations  are  also  shown.  A list  of  those 
demands  which  the  resource  type  is  not  capable  of  handling  is  also  presented 
in  this  table. 


b.  Resource  Allocation  Table.  For  each  group  defined 
in  the  input  data,  a table  is  printed  depicting  the  resource  allocation  at  the 
various  stations.  Within  this  table,  the  group  number  and  latitude  and 
longitude  are  given.  The  name  of  each  station  in  the  .group  is  also  presented 
along  with  its  latitude  and  longitude  and  type  designator  (i.e.,  air  or 
non-air  station).  The  type  designator  of  each  resource  that  is  available  at 
each  station  is  then  listed.  For  each  type,  the  quantity,  dispatch  delay,  the 
hourly  operating  cost,  and  the  reliability  probability  are  then  given. 

c.  Search  Resources.  If  the  user  has  chosen  to 
specify  the  resources  to  be  used  for  search  cases  rather  than  allowing  the 
program  to  do  so,  then  two  tables  are  printed  out  to  echo  back  the  choices. 

The  first  table  lists  only  the  preferred  resources  and  the  second  provides  a 
composite  of  the  preferred  and  alternates.  In  the  second  table,  the  type 
name,  rank  and  sector  codes  are  given.  The  sector  codes  correspond  to  those 
specified  in  the  preferred  resources  only  table. 

d.  Policy  Table.  The  user  options  for  policy 
selection  are  also  given.  The  resource  selection  policies  for  routine  cases, 
economic  and  station,  are  listed  in  the  printed  table  as  ROUTINE  ECONOMY  and 
ROUTINE  FACILITIES.  The  resource  selection  policies  for  severe  cases, 
interruption  and  station,  follow  in  the  printed  table  as  SEVERE  INTERRUPT  and 
SEVERE  FACILITIES.  The  crew  change  policy  and  the  search  resource  selection 
method  follow  under  the  titles,  CREW  and  SEARCH,  resDecti vely.  The  nonsearch 
and  search  accompaniment  policies  then  follow  as  NSMIX  and  SMIX. 

e.  Dispatch  Oelavs.  The  dispatch  delay  times  are  ■ 
presented  tabularly  on  the  same  page  as  the  policy  table. 

f.  Resource  Speeds  Table.  The  speeds  of  the  resources 
are  presented  tabularly  by  resource  type.  The  speeds  include  the  maximum 
operating  soeed  for  two  seastates  (where  rough  implies  greater  than  5 feet  and 


calm  is  less  than  or  equal  to  5 feet),  the  towing  speed  for  the  same  two 
seastates,  and  the  normal  operating  speed.  Additionally,  this  table  includes 
the  search  effectiveness  coefficient,  i.e.,  where  1 indicates  no  change  and  2 
indicates  a doubling  of  the  speed  so  that  the  search  activity  is  completed 
twice  as  fast. 


g.  Patrol  Attributes.  The  patrol  data  which  is  user 
specified  is  also  echoed  back  on  the  output  report.  These  data  include  the 
patrol  events,  names,  and  the  patrol  resource  name  and  station.  The  patrol 
position  (latitude  and  longitude  specified  in  radians)  and  the  diameter  of  the 
coverage  area.  Both  the  periodic  and  initial  event  times  are  presented  along 
with  the  on  scene  time.  The  patrolling  activity  is  printed  out  along  with  the 
mechanism  for  activating  the  patrol. 

h.  Crew  Table.  The  last  printed  table  of  the  input 
data  depicts  the  crew  allocations  at  each  station.  The  table  lists  the  ready 
crews  and  standby  crews  at  each  station  separately.  The  status  (weekdays, 
weekends,  or  weekdays  and  weekends)  and  the  quantity  of  each  is  given  for  each 
station. 


i.  Miscellaneous  Output.  Other  input  parameters  are 
printed  out,  including  the  standby  crew  delay  time,  tow-handoff  distance  and 
wait  time  restrictions , and  the  tow-hookup  time.  The  district  wide  crew  shift 
times  and  the  times  for  checking  queues  are  also  printed  here.  The  zone 
number  and  sunrise  and  sunset  values  are  also  printed  here.  The  three  failure 
criteria  times,  response,  transit,  and  locate  are  also  printed  in  this 
grouping  of  data.  The  items  printed  include  the  station  and  homeport 
refueling  times. 

3.3  General  Capabilities  and  Functions 

When  a case  is  presented  to  the  SIMULATOR,  the  first  problem  to  be 
solved  is  that  of  selecting  an  ordered  set  of  capable  resources  to  service  the 
case.  This  is  accomplished  by  considering  the  Case's  attributes,  the 
resource's  ability  to  satisfy  the  client's  needs,  the  relative  distances 
between  the  candidate  resource's  location  and  the  client's  location,  and  the 
time  for  the  resource  to  get  underway  which  includes  standby  crew  delays. 


A '’capable"  responder  is  an  individual  resource  type  which  meets  a 
hierarchy  of  screening  tests.  The  tests  are  checks  to  insure  that  the 
responder  can  satisfy  the  needs  of  the  Casa  for  which  the  responder(s)  is 
being  selected  to  serve.  The  following  checks  are  made  while  attempting  to 
select  a resource: 


1.  Check 

2.  Check 

3.  Check 
A.  Check 
5.  Check 

operate  at  night. 

5.  Check 
7.  Check 
3.  Check 
9.  Check 

at  night. 


crew  availability, 
resource  reliability, 
resource  weather  limitations, 
crew's  endurance  limitations. 

sunrise  and  sunset  limitations  if  resource  is  not  able  to 
fuel  endurance. 

distance  offshore  limitations, 
if  resource  can  handle  demand(s). 

service  time  with  sunset  if  resource  is  not  able  to  operate 
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To  establish  candidacy,  a resource  must  be  available.  A resource  is 
available  if  it  is  not  servicing  a case  or  refueling.  It  is  also  available  if 
the  case  to  be  serviced  is  severe,  and  the  resource  being  considered  is 
servicing  a routine  case. 

Once  the  list  of  candidate  resources  has  been  determined,  a check  is 
made  using  a coefficient,  which  defines  the  probability  of  "failure" 
immediately  prior  to  assignment.  One  minus  the  coefficient  is  equal  to  the 
probability  that  the  resource  is  down  for  maintenance  or  repairs.  In  this 
version  of  the  SRM,  downtime  distributions  are  not  used  to  queue  the  faulty 
resource  for  a specified  time  interval,  instead  1-coefficient,  is  tested 
against  a random  number  to  see  if  this  resource  will  remain  on  the  list  of 
candidates  to  respond  to  the  Case  being  processed. 

Each  resource,  to  remain  a candidate  for  "capable"  responder,  must 
have  a crew.  Once  the  crew  is  assigned  it  remains  with  the  resource  from  the 
time  it  departs  the  station  until  it  returns  no  matter  how  many  Cases  the 
resource  might  have  served  while  underway. 

As  stated  in  section  3.2,  the  analyst  controls  the  number  of  hours 
that  a crew  can  remain  on  duty  aboard  a particular  resource.  This  is  called 
crew  endurance.  If  the  crew  endurance  limits  are  reached  while  underway,  the 
resource  must  return  to  base  immediately  and  no  attempt  is  mace  to  find  a 
replacement  crew. 

It  is  important  to  distinguish  between  the  above  method  of  limiting 
the  crew's  working  hours  as  opposed  to  being  based  on  the  total  hours  that  the 
crew  is  on  duty  during  a calendar  day.  if  a resource  returns  to  its  station 
due  to  crew  endurance  limitations,  the  crew's  total  operating  hours  are  reset 
to  zero  and  the  same  crew  could  go  immediately  on  another  Case.  In  other 
words,  the  limiter  is  crew  endurance  per  underway  operating  hours  and  not  crew 
endurance  per  calendar  day  hours. 

If  the  Case  is  a rescue,  the  SIMULATOR  will  attempt  to  send 
responders  that  are  to  satisfy  the  need(s)  of  the  client.  During  this 
"matching"  transaction,  certain  resources  would  be  disqualified  due  to  their 
incapacity  to  perform  certain  kinds  of  service,  i.e.,  a helicopter  may  not  be 
able  to  do  a towing  job  or  a boat  cannot  provide  an  air  escort.  If  the  Case 
is  a search,  the  needs  are  not  known  apriori  so  after  the  client  is  located 
the  "matching"  process  is  applied  as  above. 

The  service  time(s)  for  a demand(s)  is  not  a function  of  resource 
type,  i.e.,  one  type  of  responder  is  not  considered  better  able  to  perform 
service  on  a particular  client's  need,  than  another  type  of  resoonder.  The 
responder  is  compelled  to  spend  the  amount  of  time  which  was  assigned  to  the 
demand  in  the  OEM.  Upon  Case  entrance  into  the  system,  these  service  times 
are  included  in  the  necessary  calculations  for  testing  range  restrictions .. 

Certain  range  restrictions  must  be  imposed  on  each  -esource  type  oy 
the  analyst.  It  is  possible  that  a particular  craft  should  not  be  operated 
within  a given  offshore  boundary  or  travel  past  a certain  distance  f'-om  its 
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home  station.  Crew  safety,  the  craft's  physical  characteristics , regulations , 
rescue  equipment  limitations,  etc.,  are  some  of  the  reasons  for  these 
restrictions . 

• Each  resource  type  has  certain  physical  characteristics  which  m^y 
prevent  it  from  capaOly  performing  functions  such  as  towing,  escorting  and/or 
operating  in  certain  weather  conditions.  The  SIMULATOR  may  send  lesser 
qualified  responders  to  a Case  if  other  resources  with  greater  competence  do 
not  exist  at  the  time  of  the  Case  occurrence,  i.e.,  an  unavailable  resource 
type  may  be  able  to  cover  more  search  miles  or  travel  faster  as  a function  of 
sea  state  to  a severe  Case.  The  Case  attributes,  sea  state  and  visibility, 
may  completely  prevent  a resource  from  performing  on  a particular  Case.  This 
is  of  course  also  true  in  the  real  SAR  system. 

The  resource  must  have  enough  fuel  to  complete  the  Case  based  on  its 
fuel  consumption  rate  and  capacity  and  the  estimated  duration  of  the  Case. 

The  time  to  transit  to  and  from  the  Case  coordinates  added  to  the  service 
times  is  used  to  estimate  this  duration  if  the  Case  is  a nonsearch.  If  the 
Case  is  a search,  the  service  times  are  not  known  apriori,  so  a user  input 
variable  is  used  in  lieu  of  service  time  to  estimate  the  minimum  amount  of 
time  that  the  search  responder  will  be  on  the  Case.  (See  Sarsim's  User's 
Gu i de , reference  10,  Table  15,  "User  Control  Input  to  the  SRIM" ) 

Certain  designated  refueling  type  resources  may  be  allowed  to 
stopover  along  the  way  for  fuel  replenishment.  (This  will  be  discussed  in 
detail  in  section  3.3.1  below).  If  the  case  is  a nonsearch,  lack  of  enough 
fuel  to  travel  to  and  from  the  Case  will  disqualify  the  candidate.  Searching 
responders  will  return  when  their  supplies  run  low. 

The  resource  must  be  able  to  remain  on  scene  for  a minimum  amount  of 
time  predetermi ned  by  the  analyst,  e.g.,  if  this  amount  of  time  were  1 hour 
and  the  responder  had  only  enough  fuel  to  remain  in  the  area  for  1/2  hour,  the 
resource  would  not  be  sent  on  the  Case.  Without  this  constraint  a -esoonder 
may  travel  a far  distance  to  a client  only  to  stay  for  a few  minutes  before 
returning  home  to  refuel. 

Some  resource  types  may  not  be  able  to  operate  at  night.  If  this  is 
true,  the  total  estimated  time  to  complete  a Case  must  fall  within  the  time 
remaining  until  sunset  or  the  affected  responder  will  be  judged  as  incaoable. 
If  the  Case  is  a search,  the  responder  will  be  sent  home  before  sunset.  If 
the  Case  is  a nonsearch,  the  total  time  to  service  the  demand(s)  must  be  taken 
into  consideration.  Any  demand  that  would  cause  the  resource  to  return  after 
sunset  is  not  assigned  to  the  resource. 

3.3.1  Refueling 

The  analyst  can  designate  certain  '-“sources,  (usually 
aircraft),  as  having  the  ability  to  refuel  at  sites  other  than  their  home  - 
stations.  As  well  as  flagging  the  refueling  type  resource,  RTR,  the  analyst 
must  also  define  each  refueling  site.  These  sites  can  be  collocated  with 
other  stations. 


Consideration  of  this  special  type  of  resource  is  done  as 
a last  resort,  i.e.,  after  every  attempt  has  been  made  to  assign  the  full 
complement  of  responders  to  a given  Case,  there  is  still  need  for  more 
qualified  resources  to  fill  the  quota. 

Normal  selection  procedures  treat  the  RTR  in  the  same 
manner  as  the  other  resources.  However,  if  the  RTR  is  not  selected  via  the 
special  refueling  algorithm  it  cannot  stopover  at  refueling  sites  on  the  way, 
i.e.,  the  screening  tests  described  above  do  not  allow  a responder  to  be  sent 
on  a Case  unless  it  has  enough  fuel.  Only  when  the  RTR  is  selecteo  by  the 
special  refueling  algorithm  will  it  be  allowed  to  stopover  at  refueling  sites 
along  the  way. 


No  deviations  are  allowed  from  the  refueling  path  due  to 
preempts.  See  Section  3.3.2.  If  another  severe  Case  were  to  occur  in  close 
proximity  to  the  traveling  RTR,  the  RTR  would  not  stray  from  its  predetermined 
path.  This  is  somewhat  unrealistic,  especially  if  the  original  Case  is 
routine,  but  will  probably  occur  infrequently. 

The  refueling  function  of  the  SIMULATOR  presents  some  very 
complex  problems  which  are  not  fully  addressed  in  this  version  of  the  model. 
For  instance,  if  preempting  were  allowed  many  possible  decisions  would  need  to 
be  considered  based  on  the  relative  location  of  the  RTR  with  respect  to  the 
refueling  sites  and  both  Case  locations,  the  amount  of  fuel  remaining  at  the 
"interrupt"  point  in  time,  the  time  to  transit  to  both  Cases,  crew  endurance, 
etc.  In  the  real  world,  weather  forecasts,  the  likelihood  of  finding  the 
client(s)  if  searching  were  involved,  uncertainties  connected  with  the 
information  received  while  enroute,  adequacy  of  the  various  stopover 
facilities  and  paradigms  due  to  human  experience  have  decided  influence  on  the 
strategies  which  are  beyond  the  scope  of  this  work  and  indeed  simulation 
techniques  in  general. 

The  goal  in  this  version  of  the  moael  is  to  set  up  an 
itinerary  for  the  RTR  such  that  it  will  arrive  at  the  Case  in  the  earliest 
possible  time  and  be  able  to  spend  the  maximum  amount  of  time  on  the  scene. 
These  were  thought  to  be  adequate  quasi-oojecti ves  due  to  the  likelihood  of  a 
rescue  case  becoming  more  severe  as  the  waiting  time  increased  and  if 
searching  is  required,  the  RTR  will  not  contribute  to  reducing  the  total 
effective  miles  searched  until  it  arrives  on  scene,  (see  section  3. A. 2 for 
Search  Case  Processing) 

The  SIMULATOR  allows  a maximum  of  two  refueling  stations 
for  stopovers:  the  nearest,  NRF,  and  the  next  nearest,  NNRF,  site  from  the 
Case.  The  methodology  used  in  setting  uo  the  itinerary  for  the  RTR  differs  as 
to  whether  the  RTR  is  going  to  a Case  or  is  returning  from  a Case. 

If  the  RTR  is  going  to  a Casa,  the  algorithm  first 
attempts  to  sand  the  RTR  directly  to  the  Casa,  search  or  perform  service,  and 
then  travel  to  the  nearest  refueling  site  to  refuel  for  a predetermined  length 
of  time.  See  figure  3.3.1  A.  If  the  Casa  is  a search,  the  RTR  may  return  to 
the  search  area  if  the  client  is  not  found  by  the  time  his  supply  of  fuel  is 
replenished. 


If  it  is  not  possible  to  go  directly  to  the  Case  due  to 
lack  of  fuel,  the  algorithm  will  attempt  to  send  the  RTR  to  the  nearest 
refueling  site,  refuel  for  the  specified  period  of  time  and  then  travel  to  the 
Case.  See  figure  3.3.1  8. 

If  the  above  path  is  infeasible,  the  algorithm  attempts  to 
send  the  RTR  to  the  next  nearest  refueling  site,  refuel , and  travel  straight 
to  the  client's  given  location.  See  figure  3.3.1  C.  If  further  refueling  is 
needed  while  processing  a search  Case,  the  RTR  would  refuel  at  the  nearest 
refueling  site  thus  maximizing  the  amount  of  time  that  a RTR  can  remain  on 
scene. 


If  none  of  the  above  paths  are  feasible,  a final  attempt 
is  made  to  have  the  RTR  refuel  at  both  refueling  sites.  See  figure  3.3.1  D. 
The  SIMULATOR  only  allows  refueling  at  two  sites  so  if  this  path  is 
unattainable  the  RTR  is  no  longer  considered  a candidate.  It  is  certainly 
possible  that  a third  site  may  achieve  feasibility,  but  the  added  complexity 
would  not  compensate  for  the  large  waiting  time  incurred  due  to  the 
accumulated  refueling  times.  It  is  expected  that  most  of  the  time  one  site 
will  be  used  and  if  the  RTR  is  located  a great  distance  from  the  Case  it  is 
likely  that  another  resource  would  become  available  to  service  the  queued  Case 
in  a more  timely  fashion. 

When  an  RTR  is  returning  home,  the  algorithm  attempts  to 
send  the  RTR  via  the  most  direct  route  so  that  it  will  arrive  heme  in  the 
earl iest  possible  time. 


The  algorithm  attempts  to  send  the  RTR  directly  home  from 
its  present  location  when  service  is  completed.  If  this  is  not  possible,  the 
algorithm  trys  to  route  the  RTR  to  the  nearest  refueling  site  before  sending 
it  home.  See  figure  3.3.1  E.  This  path  may  not  be  feasible  in  which  case  the 
RTR  attempts  to  go  to  the  next  nearest  refueling  sice.  See  figure  3.3.1  F. 

If  both  the  above  paths  are  infeasible,  the  RTR  is  routed 
through  both  refueling  sites.  This  must  be  a feasible  path  because  of  the  way 
in  which  the  RTR's  are  routed  to  Casas.  See  figure  3.3.1:  A,8,C,Q. 

3.3.2  Preempting 


Resources  enroute,  returning  from,  towing  or  escorting  a 
client  on  a routine  Casa  can  be  considered  when  selecting  responders  for 
severe  Cases.  If  an  underway  resource  is  selected  as  a responder,  it  will  be 
diverted  to  the  scene  of  the  severe  incident.  Clients  being  towed  which  lost 
their  servicing  resource  to  a severe  Case  will  have  the  time  and  position 
updated  and  remaining  ser-'-'ce  required  queued  until  a qualified  reponder  can 
be  assigned  to  continue  the  service. 


In  selecting  candidate  resources  on  routine  Casas  for 
possible  diversion  to  a severe  Case,  the  only  criteria  for  selection  is  that 
the  underway  responder  be  qualified  and  be  the  earliest  calculated  arrival  at 
the  scene.  The  specific  activity  that  the  resource  was  performing,  (other 
than  searching  or  servicing  a demand  on  scene),  does  not  affect  selection. 
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If  a responder  is  on  scene  servicing  demands  or  searching 
it  will  not  be  preempted  for  a severe  Casa.  The  basic  problem  encountered  is 
accounting  for  the  amount  of  service  time  left  after  preemption  since  the 
service  times  are  assigned  apriori.  Also,  most  demands,  except  for  cows,  are 
of  a severe  nature,  so  the  impact  of  this  limitation  is  probably  minimal. 


The  SIMULATOR  makes  no  attempt  to  find  another  resource  to 
service  the  queued  routine  Case  at  the  exact  time  that  the  diversion  takes 
place.  At  a later  time,  an  underway  responder  may  travel  to  the  queued  Casa 
when  it  becomes  available. 


The  resource  assignment  policies  can  affect  preempting  in 
the  sense  that  both  underways  and  stations  can  be  put  into  the  set  of 
candidate  responders  and  the  analyst  can  control  the  order  in  which  they  are 
checked.  For  example,  if  the  analyst  has  elected  to  have  stations  checked 
before  underways,  the  SIMULATOR  will  deduce  from  the  speeds  and  relative 
locations  of  the  stations  the  earliest  arrivals  ignoring  the  underways  unless 
all  the  responders  could  not  be  assigned  at  the  station. 


3.3.3 


Patrols 


Selected  resources,  including  auxiliary  units,  can  be 
assigned  to  patrol  areas  with  the  duration  of  the  patrol  specified  by  the 
analyst.  A resource  so  designated  will  depart  from  its  home  station  to  arrive 
at  the  patrol  area  center  at  a user  determined  time.  For  the  duration  of  the 
patrol,  the  resource  will  either  remain  at  the  center  point  or  roam  randomly 
within  a radius  of  the  centerpoint.  A '•esource  engaged  in  a patrol  will  be 
considered  in  the  determination  of  capable  resources  as  a last  '•esort,  e.g., 
if  the  Case  is  a severe  nonsearch,  the  patrol  resource  will  only  be  considered 
if  no  other  resources  can  be  found  to  service  demand(s)  left  outstanding.  If 
the  Case  is  a search  and  the  SEARCH  TABLE  policy  is  in  effect,  the  SIMULATOR 
will  try  to  locate  a particular  type  of  patrol  if  called  for  in  the  table. 

For  the  alternative  search  policy,  selection  of  a patrol  resource  is  a last 
resort  effort  to  fill  the  quota  of  missing  responders. 


The  Sarsim  User's  Guide,  reference  10,  and  section  3.2.1 
shows  the  analyst  "how  to  initially  set  up  the  patrols.  The  oatrols  can  be 
thought  of  as  a separate  simulation  or  "sub-simulation"  of  the  SIMULATOR 
unless  the  patrol  responds  to  a SAR  Case.  In  this  situation,  the 
sub-simulation  is  in  effect  "interrupted"  by  the  SIMULATOR  normal  activity 
cycles.  While  the  patrol  responder  is  on  the  SAR  Case  it  is  processed 
identically  to  the  normal  responders. 


Many  combinations  of  the  patrol's  activity  cycles  are 
possible  depending  upon  how  the  analyst  sets  up  the  patrol's  parameters  during 
input.  The  following  four  modes  are  suggested  based  on  experience  gained 
during  the  verification  phase  of  the  project: 


Let  the  oatrpl  come  into  existence  at  its  home 
station,  transit  to  the  specified  area,  stay  for  a 
time,  and  then  return  to  its  home  station  for 
termination . 


2.  Let  the  patrol  come  into  existence  in  the  area  and 
after  a given  period  of  time  has  elapsed,  (which 
could  be  the  length  of  the  simulation),  terminate  its 
existence . 

3.  Let  the  patrol  come  into  existence  in  the  area  and 
after  a given  amount  of  time  allow  the  patrol  to 
terminate  after  transiting  home. 

4.  Same  as  1 above  except  occurring  periodical ly. 

Complications  arise  when  a SAR  Case's  duration  conflicts 
with  the  times  set  up  for  a patrol  to  leave  the  scene  or  return  home.  The 
SIMULATOR  will  not  allow  the  patrol  to  go  on  Cases  where  the  estimated 
duration  of  the  Case  overlaps  the  time  that  the  patrol  is  scheduled  to  arrive 
home  and  terminate.  This  can  cause  some  unrealistic  situations  such  as;  a 
patrol  could  be  on  its  way  home  when  a severe  Case  occurs  nearby  with  no  other 
resources  available.  (Note  the  similarity  to  refueling  preempt  limitation, 
section  3.3.1.)  The  estimated  time  to  complete  the  Case  in  question  must  be 
greater  than  the  time  that  the  patrol  is  scheduled  to  terminate  at  its  home 
station;  otherwise,  the  patrol  would  not  service  the  Case.  In  the  real  SAR 
system  this  would  not  happen  if  the  patrol  resource  was  qualified  to  handle 
. the  distress-.*  • • • 

The  patrol  will  return  to  the  patrol  area  after  servicing 
a SAR  Case  if  there  is  time  left  to  spend  patrolling.  If  the  patrol  diverts 
to  a SAR  Case  while  on  its  way  to  the  area,  the  amount  of  time  originally 
scheduled  for  patrolling  is  reduced  by  the  amount  of  time  that  the  patrol 
spent  servicing  and  traveling  to  and  from  the  Case,  e.g.,  the  patrol  will 
leave  the  patrol  area  at  the  scheduled  time  pre-set  by  the  analyst,  even 
though  it  might  not  have  patrolled  the  full  planned  duration  due  to  SAR  Case 
interruptions. 

If  the  patrol  is  in  the  patrol  area  and  called  away  to 
service  a SAR  Casa,  it  will  leave  from  the  predesignated  centerpoint  unless 
the  analyst  has  set  up  the  patrol  to  roam  randomly  in  the  area.  In  the  latter 
case,  the  patrol's  location  is  found  by  sampling  from  the  circular  normal 
distribution . 

The  patrol  will  return  to  its  patrol  area  if 
enough  time  is  left  to  patrol  after  completing  its  duties  on  the  SAR  Case. 
Otherwise  the  patrol  returns  home  for  termination. 

Table  3. 3. 3. I gives  five  simple  examples  to  clarify  the 
previous  discussions. 

In  example  condition  A,  no  SAR  Cases  occur  during  the 
period  observed.  It  takes  the  patrol  1 hour  to  transit  to  the  patrol  area  and 
it  stays  there  5 hours  patrolling. 

In  example  condition  3,  a SAR  Casa  occurs  while  the  above 
patrol  is  on  its  way  to  its  area.  The  Case  causes  the  patrol  to  arrive  2 
hours  late  at  the  centerpoint.  This  results  in  the  patrol  spending  3 hours 
instead  of  the  desired  5 hours  in  the  area. 
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Example  Condition  C shows  that  the  patrol  never  did  get  to 
the  patrol  area.  This  was  a search  Case  in  which  the  patrol  had  to  leave  the 
search  area  so  that  it  would  arrive  home  at  the  necessary  time  of  7 hours 
1 ater . 


Example  condition  0 is  a situation  wherein  the  patrol  had 
to  leave  the  patrol  area  to  service  a SAR  Case.  Note  the  reduction  in 
patrol! ing  duration. 


Finally,  example  condition  E shows  the  analyst  allowing 
the  patrol  to  come  into  existance  in  the  patrol  area.  A SAR  Case  occurs  and 
instead  of  spending  the  expected  5 hours  in  the  area,  the  patrol  spends  4 
hours  due  to  the  time  loss  servicing  the  Case. 

It  is  well  to  note  that  in  all  five  examples,  the  patrol 
must  always  leave  the  area  and  arrive  home  at  the  prescheduled  time,  i.e.,  S 
and  7. 

3.4  Case  Processing 

Section  3.3  described  the  procedures  used  to  determine  resource 
capability.  This  section  outlines  how  the  Case  is  processed  once  a set  of 
capable  resources  is  chosen  for  possible  respondence. 

Fundamentally,  a Case  can  be  broken  down  into  three  distinct  types; 
rescue,  search  and  search/rescue . A rescue  is  a Case  not  involving  any 
searching.  A search  is  a Case  with  only  searching.  A search/rescue  is  a Case 
with  searching  followed  by  servicing  of  demands.  The  response  methodology  for 
each  type  differs  in  a variety  of  ways. 

The  distinguishing  feature  that  subdivides  the  rescue  Cases  from  the 
search  Cases  is  that  the  demands  of  the  client  are  known  apriori  and  are 
assigned  to  the  resource  upon  departure.  Demands  connected  with  a search  Case 
are  assumed  unknown  until  the  distressed  unit  is  located,  thereby  yielding  the 
search/rescue  type  of  Case. 

The  response  criterion  for  rescue  type  Casas  is  whether  or  not  the 
resource  is  able  to  handle  the  demand(s)  of  the  client.  Whereas,  the  deciding 
factor  for  search  type  Cases  is  the  necessity  to  fill  a given  quota  of 
particular  resource  types  needed  to  cover  the  required  amount  of  search  miles. 

The  SIMULATOR  may  not  be  able  to  send  all  the  resources  needed  to 
service  a Case  at  the  time  of  notification.  As  a result,  the  Case  is  placed 
in  a status  called  "queued".  A rescue  Casa  is  queued  if  some  or  all  the 
demands  of  the  client  cannot  be  allocated  to  the  capable  responders. 
Accordingly,  a search  Case  is  queued  if  its  full  supply  of  responders  could 
not  be  assigned  at  the  moment  of  notification. 

The  SIMULATOR  recognizes  two  categories  of  queues:  completely 
queued  and  semi-queued.  Completely  queued  implies  the  absence  of  '•esponse. 
This  is  the  generally  accepted  notion  of  a queue,  i.e.,  customers  waiting  in 
line  for  service.  The  semi-queued  Case  deviates  from  the  norm  in  the  sense 
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that  some  form  of  response  exists,  hut  the  client  requires  further 
assistance.  For  example,  a certain  aircraft,  incapable  of  tewing,  is  engaged 
in  evacuating  personnel  from  a disabled  vessel.  During  this  period  of  time, 
another  resource  cannot  be  found  to  tow  the  craft,  so  the  Case  is  semi -queued 
until  such  time  that  a capable  resource  is  sent  to  the  Case.  References  to. 
queued  Cases  include  both  completely  and  semi-queued  subsets. 

In  principal,  a search  Case  can  be  completed  without  its  full 
complement  of  responders,  whereas,  all  demands  must  be  serviced  before  a 
rescue  Case  is  completed. 

Queued  Cases  are  checked  in  the  following  order;  (1)  completely 
queued  rescue  Cases,  (2)  semi-queued  rescue  Cases  and  (3)  any  queued  search 
Cases.  The  preset  queue  check  of  stations  for  capable  resources  only  holds 
for  queued  rescue  Cases.  Hence,  only  underway  responders  will  query  queued 
search  Cases. 

Some  realism  in  handling  queued  search  Cases  is  obtained  due  to 
possible  initial  unavailability  of  some  search  resources  to  fill  the  quota, 
especially  when  the  Case  requires  a large  number  of  responders.  Consequently, 
as  the  search  progresses  additional  responders  can  be  added  to  the  search. 

This  is  similar  to  what  often  happens  in  the  SAR  system.  Nevertheless,  the 
analyst  has  no  control  over  these  assignments.  For  instance,  there  is  no 
provision  for  adding  responders  to  search  Casas  as  a function  of  how  long  the 
search  lasts.  The  addition  of  search  responders  to  queued  searen  Cases  is 
coincidental  depending  on  the  responders  becoming  available  from  completion  of 
service  on  other  Cases. 

In  the  real  world,  it  is  indeed  possible  that  a distressed  unit  may 
initiate  response  for  service  during  the  time  it  is  queued  in  the  SAR  system, 
e.g.,  a Case  first  reported  as  routine  might  have  a fire  break  out  on  board 
after  initial  notification  which  increases  the  severity  of  the  Case.  The 
client  is  unable  to  initiate  respondence  in  the  SIMULATOR.  Therefore,  queued 
Cases  in  the  SIMULATOR  are  only  checked  when  other  events  take  place  and  the 
demands  and  severity  do  not  change. 

3.4.1  Rescue  Case  Processing 

Prior  to  exercising  the  SIMULATOR,  the  analyst  must  rank 
all  possible  demands  in  order  of  increasing  importance.  As  each  candidate 
resource  passes  the  screening  tests  as  outlined  in  section  3.3,  they  enter  a 
final  phase  of  investigation  called  the  Matching  Operation,  MO.  The  procedure 
followed  is  to  try  and  "match"  the  demand(s)  of  the  client  to  the  resource  in 
order  of  decreasing  importance.  This  process  is  repeated  until  all  demands  of 
the  Casa  are  apportioned  or  the  list  of  capable  responders  is  empty. 
Unassignable  demands  cause  the  Case  to  be  queued  as  outlined  above  in  section 
3.4. 

Cases  occurring  at  night  will  be  assigned  to  a night 
capable  resource  to  service  at  least  one  demand,  if  possible.  Responders  for 
the  remaining  demand(s),  if  any,  will  be  assigned  for  service  at  first  light. 

A resource  can  be  assigned  multiple  demands  if  they  are 
not  of  the  same  type,  the  resource  is  able  to  perform  the  service,  and  the 
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service  times  associated  with  the  set  or  demands  does  not  exceed  the  maximum 
allowable  time  that  the  resource  can  remain  on  the  Case. 

As  an  analyst  option,  the  initial  response  to  an  incident 
can  be  forced  to  consist  of  both  surface  and  aviation  resource  types.  If  the 
SIMULATOR  needs  to  provide  one  of  these  types  in  order  to  obtain  the 
appropriate  mixture,  and  as  a result  the  missing  type  is  supplied  to  the  list 
of  responders  it  is  assigned  a standby  demand.  Moreover,  the  analyst  must 
define  the  service  time  for  the  standby  demand,  (see  section  3.2)  If  a 
resource  is  assigned  a standby  demand  (either  a supplied  or  actual  standby 
demand)  it  will  not  be  allowed  to  service  any  other  damands. 

In  order  to  clarify  and  expand  on  the  above  principles  a 
simple  example  will  now  be  given  for  a Case  with  multiple  demands.  Table 
3.4.1  shows  a hypothetical  importance  ranking  for  a sample  sat  of  demands. 

Table  3.4.2.  shows  some  example  apportionments  after  three 
resources  have  been  presented  to  the  MO.  The  resources  entered  the  MO  in 
order  from  left  to  right.  The  client's  ordered  set  of  demands  is: 
(MA,EV,EV,FF,TW,S8) . In  the  table,  assignment  of  a demand  to  a resource 

assumes  the  resource  is  capable  of  doing  the  demand.  - 

• 

The  first  resource  presented  for  matching  in  examole 
Condition  1,  is  an  aircraft.  The  aircraft  is  assumed  to  be  incapable  of 
towing  the  client.*  Hence,  it  is  assigned  the  set  of  demands,  (MA, EV.FF) , 
i.e.,  the  aircraft  will  perform  medical  assistance,  evacuate  some  personnel 
and  fight  a fire.  If  this  were  not  true,  some  or  all  the  demands  may  have 
been  excluded  from  the  set  above. 

Since  a resource  cannot  be  assigned  more  than  one  demand 
of  the  same  type,  the  aircraft  was  not  assigned  both  evacuation  demands.  As  a 
result,  the  boat  will  service  the  second  evacuation  demand  and  tow  the 
client.  The  standby  demand  was  not  included  in  the  boat's  set  of  demands 

because  this  type  of  demand  must  be  handled  by  a resource  with  no  other 

demands  to  service.  Therefore,  the  cutter  is  assigned  the  standby  demand. 

Example  Condition  2 changes  the  order  in  which  the 
resources  are  presented  to  the  MO.  The  boat  is  presented  first,  aircraft 
second  and  the  cutter  still  in  last  place.  The  boat  is  given  the  set, 

( MA , EV , FF , TW ) , the  aircraft  will  service  the  second  evacuation  demand  and  the 
cutter  is  still  assigned  the  standby  demand. 

Notice  the  effect  of  changing  the  order  of  presentation  of 
resources  to  the  MO!  The  boat  will  likely  have  a higher  utilization  than  the 

aircraft  and  the  Case  will  probaoly  take  longer  to  complete  because  the  boat 

will  be  much  slower  to  arrive  on  scene.  Of  course,  the  service  time  connected 
with  the  standby  demand  could  influence  the  total  time  to  complete  the  Case. 

If  the  cutter  was  delayed  and/or  had  a very  long  service  time,  the  aforesaid 
effect  might  be  cancelled  out  except  for  the  boat's  higher  utilization. 

If  the  ranking  in  Table  3.4.1  had  been  set  up  so  that  the 
standby  demand  was  moved  to  the  top  of  the  list,  i.e.,  becomes  the  most 
important  demand,  example  Condition  3 would  result  from  example  Condition  2 in 
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Table  3.4.2.  The  client's  set  of  demands  would  be  reordered: 

( SB,MA, EV, EV,FF,7W) . The  boat  would  be  given  the  standby  demand  neglecting 
all  other  demands  in  the  client's  list.  The  aircraft  would  take  the  set; 
(MA,EV,FF).  The  cutter  would  take  the  second  evacuation  demand  and  tow  the 
client. 

Severity  levels  can  change  the  order  in  which  resources 
are  presented  to  the  MO.  Example  Condition  1 may  have  been  the  result  of  the 
Case's  priority  being  severe  because  the  aircraft  would  likely  arrive  sooner 
than  the  other  resources  and  therefore  would  have  been  the  first  resource 
picked  for  presentation  to  the  MO.  Conversely,  example  Condition  2 would  be 
likely  consequence  of  the  fact  that  the  boat  was  costly  to  operate  if  the 
Case's  priority  were  routine. 

The  above  examples  should  convince  the  analyst  that  the 
assignment  of  demands  to  resources  depends  on  their  order  of  presentation  to 
the  final  matching  phase  of  the  selection  process  and  also  the  initial 
importance  ranking  of  the  possible  demand  types. 

Once  the  demand (s)  are  apportioned,  the  resource(s)  are 
. . * scheduled  to  depart  their* present  location(s)  after  a possible  delay.  An 

underway  resource  departs  immediately  to  the  Case's  reported  position.  If  the 
resource  was  at  its  station,  departure  may  be  delayed  by  two  factors:  the 
dispatch  delay  and  standby  crew  delay.  These  delays  are  additive  and  the 
resource  will  start  its  journey  to  the  reported  Case's  position  at  the  end  of 
this  time. 

All  service  other  than  tows  and  escorts,  must  be  performed 
at  the  reported  position  of  the  Casa.  The  resource  leaves  the  scene  as  soon 
as  it  has  completed  this  service.  Upon  arrival,  the  resource  performs  service 
immediately,  unless  the  only  demand  it  is  assigned  to  service  is  tow  or 
escort.  The  resource  assigned  a tow  or  escort  demand  cannot  move  the 
distressed  unit  until  completion  of  service  on  all  other  types  of  demands.  At 
which  time,  the  client  is  towed  or  escorted  to  the  nearest  station  relative  to 
the  reported  position  of  the  Case.  This  is  assumed  to  be  the  nearest  facility 

The  service  times  for  multiple  demands  by  a single 
responder  are  additive  for  all  demands  except  tows  and  escorts  which  depend  on 
the  amount  of  time  it  takas  to  move  the  distressed  unit  to  the  nearest 
facility.  This  produces  unrealistic  behavior  in  the  SIMULATOR.  In 
particular,  referring  to  Table  3.4.2,  example  Condition  1,  assuming  the 
medical  assistance  took  .3  hours,  the  evacuation  .5  hours  and  fighting  the 
fire  took  1.5  hours,  the  total  amount  of  time  that  the  aircraft  would  be 
serving  the  client  would  have  been;  .3  +■  .5  + 1.5  3 2.3  hours.  These  services 
would  likely  be  worked  on  in  parallel  in  the  SAR  system,  thus  taking  less  time 
to  accomplish.  This  would  cause  the  SIMULATOR  to  produce  higher  utilizations 
when  assigned  multiple  demands. 

Moreover,  the  aircraft  in  the  above  example  may  be 
preempted  on  its  way  to  the  Case.  Afterwards,  the  demands  might  be 
distributed  amongst  underway  resource(s).  This  produces  parallel  service  if 
more  than  one  underway  responder  was  assigned  to  the  Case  thereby  reducing 
total  service  time.  The  total  time  to  service  the  Case  would  also  vary 
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depending  on  the  arrival  times  of  these  responders,  [n  short,  the  degree  of 
parallelism  lacks  apparent  causal  ccnnectipn  in  the  SIMULATOR. 


If  pn  scene  coverage  from  start  to  finish  of  service 
occurs,  it  is  also  only  coincidental . That  is,  once  a resource  is  through 
servicing  its  demand(s)  on  scene  it  leaves  immediately.  Although,  a resource 
assigned  to  tow  or  escort  a client,  would  remain  on  scene  until  all  servicing 
is  completed  it  does  not  do  so  to  provide  coverage. 

After  responders  complete  service  they  return  home  using 
operational  speed  unless  they  are  called  upon  to  service  a queued  Case.  Upon 
arrival  at  its  home  station  the  resource  is  returned  to  ready  status  and  its 
crew  returned  to  the  appropriate  ready/standby  pool  of  crews.  The  fuel  and 
endurance  are  reset  in  preparation  for  responding  again. 

3. A. I. I Tow-handoff  Processing 

The  analyst  can  designate  certain  resources  as 
tow-handoff  Vehicles,  TV's,  and  they  are  not  allowed  to  tow  a client  to  the 
nearest  facility  unless  the  facility  happens  to  be  the  TV's  home  station, 
tow-handoff  resources  are  different  from  regular  tow  type  resources  that  can 
tow  to  their  home  station  as  well  as  to  the  nearest  facility. 

The  SIMULATOR  allocates  tow  or  escort  demands  to 
TV's  as  a last  resort,  i.e.,  no  other  resources  can  be  found  to  handle  the  tow 
or  escort  demand  in  the  MQ.  For  example,  in  Table  3. A. 2,  example  condition  A, 
the  cutter*would  have  taken  the  tow  demand  if  the  boat  were  the  only  resource 
designated  as  a TV.  However,  if  the  cutter  was  also  a TV,  the  boat  would  have 
taken  the  tow  demand  and  it  would  be  handled  in  the  manner  described  in  this 
section. 

The  TV’s  simulate  a type  of  resource  which  is 
assigned  a tow  but  the  nearest  facility  relative  to  the  Case's  reported 
position  cannot  accomodate  the  resource.  Therefore,  the  resource  must  either 
tow  the  unit  to  its  home  station,  which  may  be  very  far  away  or  tow  the  unit 
closer  to  shore  where  another  resource  might  become  available  to  relieve  the 
TV  along  the  way. 

The  SIMULATOR  approximates  the  above  situation 
by  allowing  the  analyst  to  define  a distance  offshore  from  the  nearest  station 
relative  to  the  client's  position  thereby  determining  a rendezvous  point  for 
possible  relief  by  another  resource  capable  of  towing  the  client  the  rest  of 
the  way  to  the  nearest  station.  Moreover,  the  analyst  inputs  the  maximum 
amount  of  time  that  the  TV  is  to  wait  at  this  location  before  towing  the 
client  to  its  home  station. 

The  Tow-handoff  processing  essentially  treats 
the  Casa  as  though  it  were  semi-queued.  Selection  of  a relief  is  done  in  . 
accordance  with  the  orocedures  explained  in  section  3. a.  for  queued  Cases.  If 
a qualified  responder  is  found  to  relieve  the  TV,  the  responder  will  either 
proceed  to  the  rendezvous  point  or  the  reported  position  of  the  Case, 
depending  on  the  location  of  the  TV.  If  the  TV  has  not  yet  arrived  on  scene 
at  the  reported  position  of  the  Case,  the  relief  responder  will  head  for  these 


coordinatss.  The  TV  will  not  provide  coverage  while  the  responder  is  enroute 
to  the  scene.  If  the  TV  has  already  left  the  scene  with  the  client  in  tow, 
the  relief  responder  will  travel  to  the  rendezvous  point.  Conversely,  the  TV 
will  provide  coverage  in  this  situation.  Finally,  the  distressed  unit  will  be 
towed  to  the  TV's  home  station,  if  a relief  responder  has  not  been  found 
before  the  predetermined  amount  of  time  that  the  TV  is  forced  to  wait  at  the 
rendezvous  location. 


3. 4. 1.2  Abort  Processing 

An  abort  is  defined  as  the  premature 
interruption  of  a responder  while  enroute  to  service  a Case. 

Although  somewhat  confusing,  the  SIMULATOR 
treats  the  abort  condition  as  if  it  were  a demand.  Service  times  for  these 
psuedo  demand  types  are  zero.  At  the  time  when  the  abort  takes  place  the 
responder  is  freed  from  further  obligations  to  the  Case.  As  with  standby 
demands,  the  responder  assigned  an  abort  demand  cannot  have  other  demands  to 
service. 


A resource  can  abort  a Case  in  three  ways.  In 
the  first  instance,  the  resource  is  predestined  to  abort  at  the  time  the  abort 
demand  is  assigned  in  'the  MO.  The  distance  that  the  resource  is  to  travel 
from  its  home  station  is  given  in  lieu  of  service  time  for  this  type  of 
demand.  The  resource  will  depart  and  transit  to  a point  on  a straight  line 
between  its  station  and  the  reported  Case's  coordinates.  No  preempting  is 
allowed  for  the  forced  abort.  Moreover,  it  immediately  returns  home  without 
checking  queued  Cases  after  reaching  the  above  position. 

The  second  type  of  abort  occurs  when  a responder 
is  on  the  way  to  a search  and  the  search  is  terminated.  The  responder  does 
not  continue  to  the  search  area.  It  will  abort  at  its  present  location  and  be 
available  to  service  queued  Cases  or  return  to  its  station. 

The  third  type  of  abort  occurs  when  a TV  on  the 
way  to  a Case  is  to  be  relieved  of  the  tow  at  the  Case's  position.  A TV  on 
its  way  to  the  reported  position  of  a Case  with  another  resoonder  scheduled  to 
relieve  the  tow  continues  to  the  Case's  coordinates  and  if  the  TV  is  not 
assigned  other  demands  it  immediately  leaves  the  scene.  That  is,  the  TV  abort 
takes  place  on  scene  whereas  the  other  two  types  take  place  before  ar-ival  on 
the  scene. 


3.4.2  Search  Case  Processing 

The  search  responders  are  subjected  to  the  same 
screening  tests  as  rescue  Case  responders.  Similarly,  selected  responders 
proceed  to  the  search  origin  in  the  same  manner  as  described  for  rescue 
responders . 


The  search  responders  start  searching  when  they  -each 
the  origin  of  the  search  area.  The  responder  does  not  roam  about  as  in  the 
real  world.  Instead,  it  is  effectively  oositioned  at  the  given  origin  of  the 
search.  Consequently,  the  passage  of  simulated  time  accounts  for  the  time 
each  spends  searching. 
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The  OEM  determines  the  total  time  spent  searching  for 
each  resource  that  was  assigned  to  the  historical  search  Case  and  from  that 
calculates  the  total  miles  searched,  TSEM.  (See  section  2.0  for  the 
details).  The  SIMULATOR'S  search  responders  must  cover  this  effective 
distance  in  order  to  terminate  the  search. 

The  same  quantity  and  types  of  resources  that  were 
utilized  historically  will  not  likely  be  the  same  as  the  SIMULATOR'S  search 
responders.  Their  relative  positions  from  the  search  origin  before  departure 
will  also  differ  from  history  thereby  producing  different  arrival  times  on 
scene. 

To  obtain  the  contribution  of  effective  miles 
searched  for  each  resource  assigned  to  a search  in  the  SIMULATOR  we  use  the 
foil owi ng  formul a: 

Miles  searched  = linear  miles  traveled  X Coverage  Factor 

where  linear  miles  traveled  is  calculated  by  multiplying  the  operational  speed 
of  the  resource  by  the  time  it  will  remain  on  scene.  The  Coverage  Factor  is  a 
weight  assigned  to  each  resource  that  can  vary  the  effectiveness  of  the 
individual  search  resource,  i.e.,  if  this  coefficient  is  less  than  one  the 
resource  would  take  longer  to  cover  the  area  than  if  it  were  greater  than  one. 

The  table  below  shows  an  example  of  a particular 
situation  at  some  time  during  the  search: 


Resource 

Helicopter 

WPB 

44  MLS 


Hours  on  Scene  Search  Speed  Factor 


Total  Miles 


"miles 


Table  3.4.3  Accounting  for  Search  Miles 

The  item,  Total  Miles  is  the  maximum  amount  of 
effective  miles  that  the  resources  could  cover,  given  that  they  all  started  at 
the  same  time.  The  amount  that  must  be  covered,  TSEM,  could  be  lass  than  or 
greater  than  this  total.  If  the  amount  were  greater  the  search  could  not  be 
completed  by  these  resources.  In  the  above  example,  a time  can  be  scheduled 
for  completion  of  the  search  if  TSEM  were  less  than  1030  miles.  Furthermore, 
if  the  resources  all  arrived  on  scene  at  the  same  time  with  none  leaving  the 
scene  before  the  search  is  terminated,  finding  the  time  to  and  the  search  is 
trivial,  e.g.,  if  TSEM  was  300  miles  the  search  would  be  over  in  about  1/2 
hour,  i.e.,  500/(380  + 90  + 50)  * 1/2. 

However,  there  is  no  reason  to  believe  that  the  above 
simple  situation  will  be  true  in  general.  Table  3.4.4  shows  a typical 
situation  in  which  the  times  of  arrival  vary  and  the  responders  leave  the 
search  area  before  the  search  is  terminated.  The  analyst  should  study  this 
example  carefully  to  get  a feel  for  the  complications  that  arise  in 
calculating  the  time  that  the  search  must  and  before  reading  further. 


Basically,  the  problem  that  must  be  solved  is:  given 
a set  of  search  resources,  not  arriving  on  scene  at  the  same  time,  find  the 
time,  TE,  at  which  the  sum  of  the  resource's  effective  miles  is  equal  to  the 
historical  effective  miles  searched,  TSEM.  The  resources  can  operate  in 
parallel  and  may  leave  and  return  to  the  scene  before  the  search  terminates. 
The  time,  TE,  fluctuates  as  resources  arrive  and  leave  the  scene. 

The  following  algorithm  solves  this  general  problem. 
The  algorithm  is  applied  each  time  a resource  arrives  on  the  scene.  (Note: 
the  sign,  denotes  "is  replaced  by"  and  is  the  multiplication 
operator) . 

Algorithm  for  determining  the  time  to  end  the  search,  TE: 

Al:  (Initialize  and  determine  the  maximum  amount  of  time  that  the  resource 
can  remain  in  the  area,  LOT) 

TUS  » SST  - HFS  ; if  resource  must  return  before  sunset 
* infinity  ; otherwise 

. • where  SST  is  hour  -of  sunset  and  HFS  is  the  present  hour  of  trie  day  and 
TUS  is  the  time  remaining  until  sunset. 

T3F  * AMT/CX 

where  AMT  is  the  maximum  amount  or  fuel  that  the  resource  has  in  its 
tank,  CX  is  resource's  rate  of  fuel  consumption  and  T3F  is  time  that  the 
resource  can  remain  in  area  from  fuel  considerations, 
then 

LOT  * MIN(T8F,TUS)  - TR 

where  TR  is  the  transit  time  from  the  responder's  home  station  to  the 
centroid  of  the  search  area. 

A2:  (Find  the  maximum  effective  mileage  resource  can  cover,  EM) 

EM  = X*Y*L0T 

where  X is  Coverage  Factor  and  Y is  search  speed. 

A3:  (Store  maximum  amount  of  search  mileages  attainable  by  all  the  resources 
that  have  arrived  on  scene  up  to  the  oresent  time,  if  any,  in  THRES)  * 
THRES  * THRES  + EM 

A4:  (Can  a time,  TE,  be  found  for  the  end  of  the  search?) 

If  THRES  is  less  than  TSEM,  terminate  the  algorithm;  otherwise  go  on  to 
the  next  step 

A5:  (Is  this  the  first  resource  to  arrive  in  the  area?) 

If  true,  terminate  the  algorithm;  otherwise  go  on  to  the  next  step 

A6:  (This  is  not  the  first  resource  to  arrive  in  the  area!  Has  TE  been 
determined  yet?) 

If  true,  go  to  step  A13;  otherwise  continue  on  to  the  next  step 

A7:  ((Determine  the  amount  of  mileage  that  has  been  covered  by  all  the 
resources,  AM,  and  reduce  TSEM  by  this  amount) 

RTSEM  * TSEM  - AM 
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A8:  Store  all  the  resources  speeds  in  the  set  VELS. 

A9:  (Find  the  maximum  amount  of  time  each  resource  will  be  on  scene,  MAXOS) 

Store  MAXOS  in  the  set  UMAX. 

A10:  Search  the  sat,  UMAX,  for  the  first  resource  that  will  leave  the  scene. 

All:  Let  SMIL  be  equal  to  the  value  of  the  element  thus  found  in  the  previous 
step,  A10. 

A12:  Add  all  the  speeds  in  the  set  VELS  to  the  variable  SVEL 

A13:  (Determine  the  mileages  of  all  the  resources  up  to  the  present  time) 

SRSOFAR  * SVEL*SMLL 

A14:  (Can  TE  be  determined  yet?) 

If  SRSOFAR  is  greater  than  or  equal  to  RTSEM 
TE  = RTSEM/SVEL 

Terminate  the  algorithm;  otherwise  continue  on  to  the  next  step 

A15:  RTSEM  = RTSEM  - SRSOFAR 
TE  = TE  + SMLL 

Alo:  Set  the  speed  of  the  resource  just  considered  to  zero  in  the  set  VELS. 

A17:  (Process  the  next  earliest  departure  time  resource) 

Subtract  SMLL  from  each  element  in  set  TIMAX 
Go  back  to  step  A1Q 

A13:  (TE  has  been  calculated  previously,  so  this  resource  will  reduce  the  time 
to  end  the  search) 

Determine  the  amount  of  mileage  left  to  cover,  RTSEM. 

A19:  Sum  up  all  the  speeds  and  store  then  in  variable  EFS. 

A20:  (Calculate  the  percent  of  TSEM  remaining)  • / 

3 ETA  = TRO/TF 

where  TRO  is  the  time  interval  between  the  present  time,  TE,  and  TF  is 
the  passage  of  time  since  TE  was  last  calculated 

A21:  (Calculate  the  new  reduced  TE) 

TE  * BETA*R TSEM /EFS 

A22:  If  any  search  responders  will  leave  the  scene  before  TE  hours,  add  the  -■* 

amount  of  this  mileage  that  will  not  be  covered  to  RTSEM  and  recalculate 
TE  * RTSEM/ EFS 

I 

. 

While  the  responder  is  in  the  search  area  it  may 
leave  the  area  if  its  fuel  supply  is  low.  Moreover,  it  will  leave  the  area 
such  that  it  will  return  home  before  sunset  if  it  cannot  operate  at  night.  In 
the  former  instance,  the  responder  will  go  to  its  home  station  if  it  is  not  a 
refueling  type  resource  or  to  the  closest  refueling  station  if  the  analyst  has 


designated  the  responder  as  a refueling  type  responder.  After  its  fuel  is 
replenished,  it  returns  to  the  search  area  if  the  search  has  not  terminated. 

In  the  latter  situation,  the  responder  will  return  to  its  home  station  and 
remain  overnight.  The  responder  will  return  to  the  search  origin  the 
following  day  if  the  search  has  not  ended  by  then.  A refueling  type  resource 
that  is  restricted  to  operate  only  during  the  day  could  end  up  remaining 
overnight  at  a refueling  site. 

If  the  distressed  unit  has  been  located  and  requires 
servicing,  the  search  responders  assigned  to  the  search  are  checked  for 
capability  in  the  same  manner  as  prescribed  in  section  3.3  in  the  following 
order:  (1)  responders  positioned  at  the  origin  of  the  search,  (2)  responders 
scheduled  to  arrive  at  the  origin  of  the  search  and  (3)  responders  having  left 
the  origin  of  the  search  traveling  to  a refueling  station  or  their  home 
station. 

If  all  or  same  of  the  demands  have  not  been  fulfilled 
by  the  search  responders,  resource  types  at  the  stations  are  checked  in  the 
same  manner  as  described  in  section  3.4.1. 

Finally,  when  the  search  has  terminated,  all 
responders  assigned  to  the  search  and  not  servicing  demands  return  to  their 
home  stations  via  the  most  direct  route.  Responders  completing  service  are 
processed  in  the  same  manner  as  described  in  section  3.4.1. 


3.5 


Output  of  the  SIMULATOR  Reports 


reports  as  follows: 


The  printed  output  from  the  SIMULATOR  is  divided  into  four 


a. 


Summary  Statistics  bv  Facility. 


This  report  provides  a concise  table  showing  the 
individual  station  as  well  as  the  group  performance  for  a simulation  run.  The 
performance  statistics  include  the  number  of  responses,  assists,  and  sorties 
rendered  by  each  station.  A response  is  counted  each  time  a scation  provides 
at  least  one  resource  to  a case,  an  assist  is  counted  each  time  a station 
provides  the  resource  which  is  first  on  scene  but  is  not  the  closest  station, 
and  a sortie  is  counted  each  time  a resource  is  sent  to  the  case.  The  total 
number  of  responses,  assists,  and  sorties  for  the  stations  within  a group  is 
also  shown.  Following  these  three  statistics,  the  number  of  queued  cases  from 
each  station  ( i . e . , the  closest  station  to  the  case  is  credited)  is  given. 
Again,  the  group  total  is  provided.  The  next  three  statistics  provided  are 
the  average  wait  time,  the  average  transit  time,  and  the  average  distance  to 
the  scene.  The  average  wait  time  for  a facility  is  the  average  of  all  the 
times  that  each  of  the  cases  waited  from  the  time  of  occurrence  to  the  arrival 
of  a resource  (it  includes  any  dispatch  delay,  crew  delay,  transit  and  search 
time)  on  scene.  The  average  transit  time  is  the  average  of  the  elapsed  times 
for  each  case  between  dispatch  of  the  first  resource  from  the  facility  and  i ts 
arrival  on  scene  or  in  the  search  area.  It  should  be  noted  that  if  a second 
resource  is  dispatched  to  the  case  and  arrives  sooner  than  the  first 
dispatched,  then  the  time  would  be  counted  from  this  second  resource's 
dispatched  time,  i.e.,  transit  time  is  based  on  the  first  arriv'ng  '•esource's 
time.  Distances  to  the  scene  are  ca’culated  as  straight! ine  distances  from 
the  facility.  The  group  averages  for  these  statistics  represent  the  average 
of  time  (or  distances)  for  all  of  the  stations,  i.e.,  not  the  average  of  the 
station  average.  The  number  of  demands  performed  by  each  station  and  the 
group  total  is  also  provided.  Additionally,  the  resource  operating  costs  for 
each  station  as  well  as  the  costs  for  the  group  are  presented.  Utilization 
statistics  follow  and  they  include  both  resource  utilization  and  crew 
utilization  for  weekdays  and  weekends.  In  both  cases  utilization  refers  to 
the  percentage  of  total  available  hours  that  are  spent  underway.  Then,  for 
each  station,  as  well  as  the  groups,  the  number  of  standby  crews  that  were 
both  called  and  sent  out  on  sorties  is  shown.  The  standby  crew  data  is 
followed  by  the  number  of  cases  that  were  considered  severe.  The  criteria 
failures,  transit,  locate,  and  response,  which  are  discussed  in  the  section 
below  under  the  exercise  summary  report  are  also  presented  by  station  and 
group.  They  only  pertain  to  severe  cases.  Finally,  the  average  excess 
response  time  for  each  station,  as  well  as  the  excess  found  over  all  cases  for 
all  stations  within  a group,  is  given,  where  the  excess  resoonse  time  refers 
to  the  amount  of  time  it  took  the  first  resource  to  get  alongside  from 
notification  over  and  above  the  user  provided  response  failure  criteria  time. 
It  also  only  pertains  to  severe  cases. 
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0. 


Resource  Sortie  Profile. 


This  output  report  provides  a summary  of  *-esource  statistics 
by  type  (e.g.  17UTL,  95PAT,  92WPS,  HH3F,  C130)  and  by  category  (i.e.,  small 
boats,  patrol  boats,  cutters,  rotary,  and  fixed  wing  aircraft,  and  others). 

The  three  statistics  which  are  presented  are  total  operating  hours, 
utilization  (operating  hours  divided  by  total  available  hours  including  the 
down  time),  and  total  operating  costs.  These  statistics  are  presented  both  by 
type  and  category  in  two  tables.  The  types  are,  however,  listed  in  their 
categorical  order.  That  is,  all  small  boat  types  are  listed,  followed  by  the 
patrol  boat  types,  etc..  This  report  provides  a list  of  the  demand  types  and 
their  respective  frequency  of  occurrence.  Additionally,  the  percentage  of 
total  occurrence  is  given  for  each  type. 

c.  Exercise  Summary  Report. 

This  report  is  intended  to  present  some  of  the  most 
significant  summary  statistical  data  about  the  run.  It  also  provides 
information  to  help  the  user  keep  track  of  his  exercises.  That  is,  the  report 
includes  the  district  numbers,  date  of  execution,  time  period  and  dates  of  the 
simulation  and  comments  about  the  run  which  are  a user  input.  A figure  of 
merit  is  also  reported  where  the  calculation  for  this  is  explained  in  more 
detail  in  Reference  10. 

The  summary  statistics  are  divided  into  four  categories  which 
are  the  case  statistics,  some  miscellaneous  statistics,  the  resource 
statistics,  and  the  criteria  failures  for  severe  cases  only.  The  case 
statistics  are  presented  for  each  of  the  two  time  slots,  weekends  and 
weekdays.  The  total  of  the  two  time  periods  is  also  presented.  The  case 
statistics  include  the  number  of  cases  that  occurred  and  the  number  of  cases 
completed,  as  well  as  the  percentage  of  the  cases  completed.  It  should  be 
noted  that  the  cases  are  counted  according  to  the  time  slot  in  which  the  case 
occurred . 


The  miscellaneous  statistics  include  the  average  wait  time 
and  the  average  time  a case  is  in  queue.  Wait  time  is  the  elapsed  time 
between  notification  of  the  distressed  and  arrival  of  the  first  '•esponding 
resource.  The  average  queue  time  represents  the  average  of  those  cases  that 
were  in  queue  only.  The  average  distance  offshore,  total  number  of  responses, 
and  total  number  of  sorties  are  also  presented.  The  number  of  responses 
represents  the  number  of  times  a facility  responded  to  cases,  i.e.,  regardless 
of  the  number  of  resources  provided  by  a facility  for  a particular  case,  only 
one  response  is  counted.  Total  enroute  time  and  total  search  time  are  also 
presented.  Total  enroute  time  is  the  total  time  used  to  transit  to  cases  and 
total  search  time  is  the  total  time  spent  in  the  designated  search  area. 

The  summary  resource  statistics  include  the  total  ooerating 
hours,  total  utilization,  and  the  total  ooerating  costs.  Total  operating 
hours  is  the  sum  of  all  individual  resources  operating  hours.  The  total 
utilization  is  equal  to  the  total  operating  hours  divided  by  the  total  hours 
that  the  resources  are  available.  The  hours  of  availability  do  not  exclude 
those  times  during  which  a resource  is  found  to  be  down  via  the  user  provided 
reliability  probability.  The  total  ooerating  costs  is  based  on  the  hours  of 
operation  times  the  hourly  costs  for  operating  the  various  '•esource  types. 
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The  last  set  of  statistics  presented  in  this  table  includes 
the  number  of  failure  occurrences  by  type  for  severe  cases  only.  The  types 
include  transit,  locate,  and  response  failures.  A transit  failure  is  defined 
as  a case  where  the  elapsed  time  between  dispatch  and  arrival  of  the  first 
responder  on  scene  and  actual  location  of  the  distressed  unit  exceeds  the  user 
specified  time.  A response  failure  is  defined  as  a case  where  the  elapsed 
time  from  initial  notification  until  a resource  is  alongside  exceeds  the  user 
specified  time  for  such  a failure. 

d.  Facilities  Resource  Summary. 

This  report  provides  a summary  of  the  resource  usage  at  each 
station,  which  is  denoted  with  its  identifier.  Each  resource  is  listed  along 
with  the  total  number  of  sorties  it  performed  and  its  total  operating  hours 
and  utilization.  The  number  or'  the  various  demand  types  performed  by  each 
resource  is  also  presented  in  this  summary  report. 


/ 


30 


... ...  : .. . - ' Mdrn  ..  - 


Time 

Arrived 

Time  Time  at  Dock  Time  Waiting 
Time  of  Time  Arrived  Left  the  or  refuel-  Arrived  Time 


TABLE  3.2.1 

User  Control  Input  to  The  SIMULATOR 


ELEMENT 

NUMBER  ELEMENT  NAME 

1 TRACE  FLAG 


2 EVENT  TRACE 


3 SEARCH  TRACE 

A NONSEARCH  TRACE 


5 UNOERWAY  TRACE 

6 SIMULATION  OAYS 

7 START  .MONTH 

3 START  OAY 

9 START  YEAR 


DESCRIPTION 

~ 

Flag  which  activates  trace  (programmer ' s 
debugging  aid) 

1 Indicates  traces  will  be  activated 


Flags  indicating  the  desire  for  traces  of 
the  actual  case  data  for  particular  events; 


the  following  is 

a list 

of  the 

element 

numbers 

and  their 

corresponding 

events 

1 

NOSRCH 

12 

TERMPA 

2 

ABORT 

13 

ENIGMA 

3 

ARVSNE 

14 

FILLUP 

A 

HANOTOW 

15 

ARVSRH 

5 

TOWARV 

16 

L VSR CM 

6 

L'/SCEN 

17 

ARVHOM 

7 

GETHOM 

18 

STATE 

3 

GOHOM 

19 

ENOSRH 

9 

INPATR 

20 

set  to 

1 always 

10 

ACTPAT 

21 

FINIS 

11 

RTNPAT 

22 

set  to 

1 always 

Flag  indicating  the  desire  for  search  traces 


1 Indicates  traces  will  be  activated 


Flag  indicating  the  desire  for  nonsearch 
traces 

1 Indicates  traces  will  be  activated 

Flag  indicating  the  desire  for  underway 

- ••  traces 

1 Indicates  traces  will  be  activated 

Period  of  time  to  be  simulated  in  days 

Month  (1-12)  of  the  simulation  start  date 

Day  (1-31)  of  the  simulation  start  data  . 
(must  be  on  a Monday) 

Year  (last  two  digits)  of  the  simulation 
start  date 


TABLE  3.2.1  (continued) 

User  Control  Input  to  The  SIMULATOR 


ELEMENT 

NUMBER  ELEMENT  NAME 

10  JULIAN  OATE 


11  REPORT  FLAG 


12  POSTPROCESSOR  FLAG 


13  ECONOMIC  POLICY 


14  STATION  POLICY 
(ROUTINE) 


DESCRIPTION 


Julian  date  used  for  sunrise/sunset 
calculations  (corresponds  to  start  data) 

Flag  indicating  the  desire  for  printed 
output  reports 

1 Indicates  the  desire  for  the  reports 

0 Indicates  the  reports  are  to  be  suppressed 

Flag  indicating  the  desire  to  collect  and 
save  the  detailed  case  data  for  postprocessor 

0 Indicates  the  recording  of  the  data 
should  be  suppressed 

7777  Indicates  the  desire  for  the  data 

Economic  policy  code  for  resource  selection 

1 Selection  based  on  hourly  ranked  cost, 
i.e.,  seek  the  minimum  ranking 

2 Selection  based  on  hourly  ranked  cost  * 
transit  time,  i.e.,  seek  the  minimum  transit 
cost 

3 Selection  based  on  speed  of  resource, 
i.e.,  seek  the  resource  that  can  arrive 
soonest 

4 Same  as  1 except  that  all  -anks  are 
equal.  Selection  is  somewhat  random  from  a 
FIFO  set. 

Policy  code  determining  the  facilities  or 
groups  to  be  checked  in  resource  selection 
for  a routine  case 

1 Select  from  nearest  station  only 

2 Select  from  nearest  group  only 

3 Select  from  nearest  station  and  adjacent 
station 
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TA8LE  3.2.1  (continued) 

User  Control  Input  to  The  SIMULATOR 

ELEMENT 

NUMBER  ELEMENT  NAME  DESCRIPTION 

4 Select  from  nearest  station  within  entire 
district,  i.e.,  attempt  to  find  a resource 
at  nearest  station  and  if  none  found,  check 
the  next  nearest  station,  etc. 


15  INTERRUPT  POLICY 


16  STATION  POLICY 
(SEVERE) 


17  CREW  FLAG 


13  SEARCH  FLAG 


Priority  interrupt  policy  code  for  resource 
selection  of  underway  resources  for  severe 
cases 

1 No  interruptions  permitted 

2 Select  from  underways,  then,  if 
necessary,  from  resource  types  at  facilities 

3 Select  from  resource  types  at  facilities 
then,  if  necessary,  from  underways 

4 Select  from  mixed  set  of  resource  types 
at  facilities  and  unde  lys 

Resource  selection  policy  code  for  severe 
cases 

1 Select  from  nearest  group  only 

2 Select  from  all  available  -esources  i.e., 
similar  to  specifying  a 4 in  element  14, 
AOJACENT 

Flag  indicating  whether  or  not  individual 
station  crew  shift  times  are  specified 

0 Indicates  station  by  station  crew  shifts 

not  being  implemented*  •*  • . - • 

1 Indicates  station  by  station  crew  shifts 
are  being  implemented  and  that  the  times  are 
specified  in  the  crew  data 

Flag  indicating  the  search  resource 
selection  method 

0 Indicates  that  the  preferred  and 
alternative  resources  for  searches  are 
specified  as  a user  input  (elements  77-33) 
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TABLE  3.2.1  (continued) 

User  Control  Input  to  The  SIMULATOR 


ELEMENT 

NUMBER  ELEMENT  NAME 


NONSEARCH  MIX  FLAG 


SEARCH  MIX  FUG 


SERVICE  TIME  FLAG 


DISPATCH  TIME  FUG 


STANOBY  TIME  FLAG 


DESCRIPTION 

1 Indicates  that  the  simulator  will  select 
the  number  of  search  resources  based  upon 
the  historical  number  of  resources 

Flag  indicating  whether  or  not  the 
accompanying  resource  policy*  is  to  be  in 
effect  for  nonsearch  cases 

0 Accompaniment  not  required 

1 Accompaniment  required 

Flag  indicating  whether  or  not  the 
accompanying  resource  policy*  is  to  be  in 
effect  for  search  cases 

0 Accompaniment  not  required 

1 Accompaniment  required 

* Accompanying  resource  policy  requires  a 
mix  of  air  and  surface  resources  on  cases 

Random  service  times  flag 

NO  Constant  service  times  for  all  demands 

YES  Random  service  times  will  be  used  for 
demand  servicing.  Means  are  given  in 
element  126 

Random  dispatch  delay  flag 

NO  Constant  dispatch  delay  times 

YES  Random  dispatch  delay  times.  Given 
dispatch  delays  are  used  as  means  (elements 
121-122). 

Random  standby  times 

NO  Constant  standby  times.  Element  29  is  a 
constant  standby  delay. 

YES  Random  standby  times.  Element  29  is  a 
mean  standby  delay. 
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TABLE  3.2.1  (continued) 

User  Control  Input  to  The  SIMULATOR 


ELEMENT 

NUMBER 

ELEMENT  NAME 

DESCRIPTION 

24 

SEARCH  OFFSHORE 
CRITERIA 

Distance  offshore  which  defines  search 
resource  group  classification  (n.  mi . ) 

* Element  24  need  only  be  specified  if 
element  13  is  a 0. 

25 

TOW  HANOOFF  OFFSHORE 

01  STANCE 

Minimum  distance  from  shore  required  to  tow 
(n.  mi.),  i.e.,  distance  where  a tow-handoff 
would  take  place 

25 

TOW  HANOOFF  WAIT  TIME 

Time  resource  will  wait  for  a handoff  (hours 

27 

TOW  HOOK  UP  TIME 

Time  it  takes  to  hook  up  for  a tow  (hours) 

28 

STAN08Y  SERVICE  TIME 

Service  time  for  accompanying  resources 
performing  only  a standby  demand 

* Element  28  specified  only  if  element  19  or 
20  is  set  to  1. 

29 

STAND8Y  CREW  HOURS 

Constant  or  mean  time  to  ready  a standby 
crew  (hours).  See  element  23. 

30 

AIRCRAFT  REFUELING 
TIME 

Time  to  refuel  an  aircraft  at  any  refueling 
station  (hours) 

31 

RESOURCE  REFUELING 
TIME 

Down  time  to  refuel  a craft  at  its  home 
station  (hours) 

32 

CREW  SHIFT  TIME 

Time  to  shift  a standby  crew  to  ready  status 
(time  of  day  based  on  twenty-four  clock), 
e.g.,  2230  = 22.5 

33 

CREW  SHIFT  TIME 

Time  to  shift  the  ready  crew  back  to  standby 
status  (hours) 

* Elements  32  and  33  are  negative  if  the 
district  wide  crew  shift  is  not  being 
implemented  and  apply  only  to  district  wide 
crew  shifts. 

34 

RESPONSE  CRITERIA 

Response  failure  criteria  time  (hours) 

35 

TRANSIT  CRITERIA 

Transit  failure  criteria  time  (hours) 

36 

LOCATE  CRITERIA 

Locate  failure  criteria  time  (hours) 

36 
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ELEMENT 

TABLE 
User  Control 

3.2.1  (continued) 

1 Input  to  The  SIMULATOR 

NUMBER 

ELEMENT  NAME 

DESCRIPTION 

37 

EVENT  TIME 

Time  for  activating  an  event,  which 
accumulates  statistics,  but  no  longer  used, 
so  best  set  to  0.0 

38 

QUEUE  CHECK  FLAG 

Flag  indicating  whether  or  not  calling  READI 
to  check  the  queued  cases  is  desired 

1 Indicates  wants  to  check  queues  and  that 
the  data  follows 

3 1 Indicates  that  queues  should  not  be 

checked 

39 

NUMBER  OF  TIMES  TO 

CHECK  QUEUES 

Number  of  times  during  each  day  that  queues 
will  be  checked  (this  number  of  times 
f o 1 1 ows ) 

40 

TIMES  TO  CHECK  QUEUES 

Times  of  the  day  to  check  queues  (24-hour 
clock) 

41 

TIME  TO  START  TRACES 

Time  to  start  snapshot  dumps  (days) 

42 

TIME  TO  STOP  TRACES 

Time  to  stop  snapshot  dumps  (days) 

43 

TIME  ZONE 

Time  zone  of  the  district  from  Greenwich, 
e.g.,  Eastern  seaboard  is  district  5 used 
for  sunrise/sunset  calculations 

44 

ECHO  FLAG 

Flag  indicating  option  for  printing  the 
input  data 

9999  Input  data  printed 

- 9999  Printout  of  input  data  suppressed 

45 

PATROL  FLAG 

Flag  indicating  patrol  options 

0 No  patrols 

1 Patrols  a'-e  specified  (see  elements 
107-120) 

46 

SUNRISE/ SUN SET  FLAG 

Flag  specifying  constant  or  calculated 
sunrise  and  sunset 

1 Constant  sunrise  and  sunset 

3 1 Calculated  sunrise  and  sunset 

57 

TA81E  3.2.1  (continued) 

User  Control  Input  to  The  SIMULATOR 


ELEMENT 

NUM8ER 

ELEMENT  NAME 

DESCRIPTION 

47 

SUNRISE  TIME 

Time  of  day  for  sunrise  (hours);  specified 
only  if  constant  time  desired;  24-hour  clock 

48 

SUNSET  TIME 

Time  of  day  for  sunset  (hours);  specified 
only  if  constant  time  desired;  24  hour  clock 

49 

NUM8ER  OF  CATEGORIES 

Number  of  resource  categories.  Set  to  6 

50 

NUM8ER  OF  TYPES 

Number  of  resource  types  following 

51 

NAME 

Name  of  resource  type 

52 

COST 

Operating  cost  of  resource  per  hour  (dollars) 

53 

TOW  LIMIT 

Maximum  tonnage  that  can  be  towed  at  given 
speeds 

54 

AIR/SURFACE  FLAG 

Flag  indicating  traveling  medium 

0 surface 

1 air 

55 

SEA  STATE 

Maximum  allowable  sea  state  for  operating 
(feet) 

56 

VISIBILITY 

Minimum  visibility  required  for  ooerations 
(n.mi . ) 

57 

ON  SCENE  TIME 

Minimum  allowable  time  on  scene  (hours) 

58 

OAY/NIGHT  FLAG 

Day  and  night  operations  flag 

0 Oay  and  night  operations,  no  refueling 

1 Oay  operations  only,  no  refueling 

100  Oay  operations  only  with  refueling 

101  Oay  and  night  operations  with  refueling 

59 

FUEL  RATE 

Fuel  consumption  (gallons/hour) 

50 

FUEL  CAPACITY 

Fuel  capacity  (gallons) 

61 

CREW 

Maximum  crew  endurance  (hours) 

58 
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TABLE  3.2. L (continued) 

User  Control  Input  to  The  SIMULATOR 


ELEMENT 

NUMBER 

ELEMENT  NAME 

DESCRIPTION 

52 

MAXIMUM  DISTANCE 

Maximum  allowable  distance  from  homeport  or 
facility  (n.  mi .) 

53 

OFFSHORE  OISTANCE 

Maximum  allowable  distance  offshore  for 
operations  (n.  mi . ) 

64 

NUMBER  OF  OEMANDS 

Number  of  assistance  demands  that  cannot  be 
performed 

55 

CATEGORY  FLAG 

Category 

1 3oat 


2 Patrol 

3 Cutter 


4 Rotary  wing  aircraft 

5 Fixed  wing  aircraft 

6 User  assigned  value 


66 

DEMANOS 

Name  of  assistance  demands  that  cannot  be 
performed  (from  user  selected  demand  names) 

67 

NUMBER 

Number  of  resource  types  with  speeds 
specified.  This  number  should  be  the  same 
as  element  50. 

63 

NAMES 

Name  of  the  resource  type 

69 

OPERATING  SPEED 

Normal  operating  soeed  (knots) 

70 

ENROUTE  SPEED 

Maximum  speed  with  a sea  state  greater  than 
5 feet  (knots) 

71 

ENROUTE  SPEED 

Maximum  speed  with  a sea  state  less  than  or 
equal  to  5 feet  (knots) 

72 

TOW  SPEED 

Towinq  speed  with  a sea  state  greater  than 
feet  (knots) 

73 

TOW  SPEED 

Towing  speed  with  a sea  state  less  than  or 
equal  to  5 feet  (knots) 
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TABLE  3.2.1  (continued) 

User  Control  Input  to  The  SIMULATOR 


ELEMENT 

NUMflEB  ELEMENT  NAME 

74  NUMBER  OF  RESOURCES 

75  .NAMES 

75  SEARCH  COEFFICIENT 


77*  NUMBER  OF  SEARCH 

RESOURCES 

78  .NAMES 

79  SEARCH  COOE 


80  NUMBER  OF  SEARCH 

RESOURCES 

31  RANK 

32  NAMES 


DESCRIPTION 


Number  of  resource  types  with  search 
coefficients  specified.  This  number  should 
be  the  same  as  element  30. 

Name  of  the  resource  type 

Search  speed  coefficient;  factor  wnich 
allows  for  improved  search  effectiveness  by 
allowing  for  earlier  completion  of  the 
search,  i.e.,  if  sat  equal  to  2.0,  resource 
would  complete  search  twice  as  fast 

Number  of  resource  types  with  search 
environment  codes  specified;  these  are  the 
preferred  resources 

* Elements  77-83  entered  only  if  element  13 
= 0 

Name  of  resource  type 
Search  environment  code 

1 Routine,  less  than  SHORE  n.mi.  offshore 

2 Severe,  less  than  SHORE  n.mi  offshore 

3 Routine,  greater  than  or  equal  to  SHORE 
n.mi.  offshore 

4 Severe,  greater  than  or  equal  to  SHORE 
n.mi  offshore 

SHORE  is  the  user  selected  variable,  element 
24 

Number  of  resource  types  considered  for 
search  assignment  as  alternates  to  those 
specified  in  element  77 

Rank  of  each  resource  type  within  a resource 
category  for  substitute  resource  assignment 
when  the  preferred  is  unavailable 

Name  of  resource  type 


TABLE  3.2.1  (continued) 

User  Control  Input  to  The  Simulator 


ELEMENT 

NUMBER  ELEMENT  NAME 

33  SEARCH  COOE 


34  NUMBER  OF  GROUPS 

35  GROUP  NUMBERS 


36  GROUP  LATITUOE 
OEGREES 

37  GROUP  LATITUOE 
MINUTES 

38  GROUP  LONGITUDE 
OEGREES 

89  GROUP  LONGITUDE 
MINUTES 

90  NUMBER  OF  STATIONS 

91  STATION  NAME 

92  TYPE  STATION  FLAG 


DESCRIPTION 


Search  environment  code 

1 Routine,  less  than  SHORE  n.mi.  offshore 

2 Severe,  less  than  SHORE  n.mi  offshore 

3 Routine,  greater  than  or  equal  to  SHORE 
n .mi . offshore 

4 Severe,  greater  than  or  equal  to  SHORE 
n.mi.  offshore 

SHORE  is  the  user  selected  variable,  element 
24 

Number  of  group  of  stations/facilities 

Unique  number  identifier  for  each  group. 
Note,  if  0,  a refueling  station  is  implied. 
The  refueling  group  must  follow  all  other 
groups.  7777  is  used  to  specify  a 
patrolling  group. 

Latitude  of  the  centroid  of  the  group 
(degrees) 

Latitude  of  the  centroid  of  the  grouD 
(minutes ) 

Longitude  of  the  centroid  of  the  group 
(degrees ) 

Longitude  of  the  centroid  of  the  group 
(minutes ) 

Number  of  stations  in  the  group 
Station  designator  (e.g.,  STAA) 

Type  of  station 

0 Non-air  station 

1 Air  station 
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TA8LE  3.2.1  (continued) 

User  Control  Input  to  The  SIMULATOR 


ELEMENT 

NUMBER  ELEMENT  NAME 

93  STATION  LATITUOE 

OEGREES 

94  STATION  LATITUDE 

MINUTES 

95  STATION  LONGITUDE 

OEGREES 

96  STATION  LONGITUDE 

MINUTES 

97*  NUMBER  OF  TYPES 


98  NUMBER  OF  A TYPE 

99  TYPE 

100  AVAILABILITY  PARAMETER 

101  DISPATCH  DELAY  FLAG 

102  RELATIVE  COST 

103  NUMBER  CREWS 

104  CREW  STATUS 


DESCRIPTION 

Latitude  of  the  station  (degrees) 

Latitude  of  the  station  (minutes) 

Longitude  of  the  station  (degrees) 

Longitude  of  the  station  (minutes) 

Number  of  resource  types  at  a station 

* Elements  97-106  are  not  entered  for 
refueling  group,  group  0. 

Number  of  a particular  type  of  resource  at  a 
station,  where  the  type  is  specified  in 
element  99. 

Name  of  the  resource  type 

Availability  parameter  indicating  the 
probability  that  the  resource  type  is 
capable  of  getting  underway  when  needed  (0. 
to  1.) 

Oispatch  delay  array  index  pointing  to 
dispatch  delay  in  list  entered  as  element 
121. 

Relative  ranking  for  resources  at  the  station 
Number  of  crews  at  each  station 
Readiness  code  for  the  crew 
Ready  crew  Standby  crew 

1 Weekdays  only  100  Weekdays  only 

2 Weekends  only  200  Weekends  only 

3 Weekdays  and  300  Weekdays  and 

weekends  weekends 
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TA81E  3.2.1  (continued) 

User  Control  Input  to  The  SIMULATOR 

ELEMENT 


NUMBER 

ELEMENT  NAME 

DESCRIPTION 

105 

CREW  SHIFT  TIME 

Time  to  begin  a crew  shift  (hours)  (24  hour 
clock) 

106 

CREW  SHIFT  TIME 

Time  to  end  a crew  shift  (hours) (24  hour 
clock) 

*Elements  105  and  106  are  specified  only  if 
element  17  is  set  to  a 1 and  only  for  ready 
crews.  Ready  crews  exist  between  these 
times . 

107 

NUMBER  OF  PATROLS 

Number  of  patrols  desired.  Enter  elements 
108-120  for  each  patrol. 

108 

PATROL  NAME 

Name  of  patrol . Must  correspond  to  a name 
given  in  element  51. 

109 

PATROL  HOME  STATION  ' 

N$me  of  the  patrol's  home  facility  or  port 

110 

CONTROL  EVENT 

Name  of  control  event 

INPATR  patrol  assignment 

RTNPAT  schedules  a return  home 
for  a patrol 

111 

PATROL  LATITUOE 
OEGREES 

Latitude  of  the  center  of  the  patrol  area 
(degrees ) 

112 

PATROL  LATITUOE 
MINUTES 

Latitude  of  the  center  of  the  patrol  area 
(minutes) 

113 

PATROL  LONGITUDE 
OEGREES 

Longitude  of  the  center  of  the  patrol  area 
(degrees ) 

114 

PATROL  LONGITUDE 
MINUTES 

Longitude  of  the  center  of  the  patrol  area 
(minutes) 

115 

PATROL  TIME 

Amount  of  time  patrol  will  remain  in  the 
area  (hours) 

US 

PATROL  OIAMETER 

Diameter  of  the  patrol  area  if  the 
patrolling  resource  type  is  not  restricted 
to  the  center  point. 
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TA8LE  3.2.1  (continued) 

User  Control  Input  to  T’ne  SIMULATOR 


! 


ELEMENT 

NUMBER  ELEMENT  NAME 
117  PATROL  FLAG 


118  PATROL  FLAG 


DESCRIPTION 

Flag  describing  patrol  activity 

' 

1 Periodic  on  scene  times 

2 Patrol  is  fixed  at  his  homeport 

3 Random  on  scene  times 

3 

Flag  describing  the  mechanism  for  starting  a 
patrol 

1 All  external 

2 Periodic  interval  start  times 


119  PATROL  SCHEDULE 

120  PATROL  START  TIME 


3  Random  interval  start  times 

Time  (days)  to  schedule  the  patrols  if  they 
are  not  external,  i.e.,  element  113  is  not 
set  to  a 1. 

Time  (hours)  event  is  to  initially  occur 


121  NUM8ER  OF  DISPATCH  Number  of  dispatch  delay  times  specified 
DELAYS 


122 

DELAYS 

Dispatch  delay  times  (hours)  See  elements 
22  and  101. 

123 

NUMBER  OF  DEMANDS 

Number  of  demand  codes 

124 

OEMANOS 

Name  of  each  demand  code 

125 

OEMANO  RANK 

Ordinal  code  accompanying  the  demand  name, 
indicating  the  service  ranking.  Enter  in 
same  order  as  ranked.  Oo  not  enter  SURCH 
.demand 

126 

MEAN  SERVICE  TIMES 

Demand  service  time  mean  if  random  service 
times  are  specificed  in  element  21 

127 

FIGURE  OF  MERIT  FACTOR 

Number  required  for  figure  of  merit 
calculation 

129 

FIGURE  OF  MERIT  FACTOR 

Number  required  for  figure  of  merit 
calculation 
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TA8LE  3.2.1  (continued) 

User  Control  Input  to  The  SIMULATOR 


ELEMENT 

NUMfiEft  ELEMENT  NAME  DESCRIPTION 

129  FIGURE  OF  MERIT  FACTOR  Number  required  for  figure  of  merit 

calculation 


130 

131 

132 

133 

134 

135 

136 

137 

138 

139  . 

140 

141 

142 


FIGURE  OF  MERIT  FACTOR  Number  required  for  figure  of  merit 

calculation 

FIGURE  OF  MERIT  FACTOR  Number  required  for  figure  of  merit 

calculation 

FIGURE  OF  MERIT  FACTOR  Number  required  for  figure  of  merit 

calculation 


FIGURE  OF  MERIT  FACTOR  Number  required  for  figure  of  merit 

calculation 

FIGURE  OF  MERIT  FACTOR  Number  required  for  figure  of  merit 

calculation 

OISTRICT  Oistrict  number  baing  simulated  (44  and  left 

justified) 

OTSTRICT  Oistrict  number  being  simulated  (A4  and  left 

justified) 


OISTRICT 

PERIOD 

COMMENTS 

COMMENTS 

COMMENTS 

COMMENTS 


Oistrict  number  being  simulated  (A4  and  left 
justified) 

Word  "PEAK"  or  "OFF PEAK" 

Comments  for  summary  output  (user  selected) 
Comments  for  summary  output  (user  selected) 
Comments  for  summary  output  (user  selected) 
31ank  card 


’I 


Rank 

Oemand  Type 

Mnemonic 

i 1 

Medical  Assistance 

MA 

2 

Evacuation 

EV 

3 

Fight  Fire 

FF 

4 

Tow 

TV/ 

5 

Escort 

ES 

6 

Standby 

S8 

I 7 

Oeliver  Equipment 

DE 

Table  3.4.1  Set  of  Demands 

Ranked  by  Importanc 

S] 


Aircraft  8oat 

Cutter 

Boat 

Aircraft 

Cutter 

MA  EV 

SB 

MA 

EV 

S3 

EV  TV/ 

EV 

FF 

FF 

' TV/ 

Condition  1 

Condition  2 

Boat  Aircraft 

Cutter 

Aircraft 

Boat 

Cutter 

SB  MA 

EV 

MA 

EV 

S3 

EV 

TW 

EV 

TW 

FF 

FF 

Condition  3 

Condition  4 

(Resources  matched  from  left  to  right) 


•Table  3 - 4>. 2 Oemand  Matching  and  Assignments 


Amount 

Effect i ve 

Search 

1 

Effective 

pf  time 

Miles 

will  be 

Type  of 

Present 

Speed  of 

it  can 

searched 

Present 

over  in 

Resource 

Time 

Resource 

remain 

so  far 

TSEM 

hours 

Notes: 

0.0 

idoo 

f 

i 

L 

HFT7I 

1.0 

ISO 

S.o 

0 

looo 

? 

2 

hOT 

to 

“TOO 

2.0 

150 

550 

f 

3 

BOAT 

3.0 

20 

200.0 

“400  " 

SOo 

25 

4 

hh  '#r 

4. A 

150 

2.0 

uso 

520““ 

11 

5 

mm 

5.0 

" 100 

2.0 

650 

350 

t 

6 

SEARCH  WILL  END  IN  7 HOURS 


NOTES 


A search  case  has  arrived  into  the  system  at  relative  time  zero  hours. 

The  total  effective  miles  that  must  be  searched  is  1000  miles. 

One  hour  later  a helicoptor,  HH  #1,  arrives  on  scene  and  begins  to  search 
with  a speed  of  150  knots.  Oue  to  fuel  constraints  it  must  leave  the 
scene  in  2 hours.  Therefore,  it  can  only  cover  150  x 2 = 300  effective 
miles  which  is  less  than  the  required  amount  of  1000  effective  miles.  So 
it  is  not  known  when  the  search  will  end. 

Another  aircraft,  HH  #2,  arrives  on  scene  1 hour  after  the  first,  HH  #1, 
or  2 hours  since  the  search  case  came  into  the  system.  The  first 
helicoptor  has  covered  150  miles  up  to  now,  so  there  is  350  miles  left  to 
search.  However,  both  these  aircraft  together  cannot  complete  the  350 
miles  given  the  amount  of  time  they  can  remain  on  the  scene.  The  analyst 
can  verify  this:  350  divided  by  (200  + 150)  is  greater  than  2 hours. 

This  is  when  the  last  aircraft  will  leave  the  scene. 

Now  a boat  arrives  that  can  stay  200  hours  in  the  area.  We  cannot  use 
the  simple  relationship  of  dividing  T3EM  by  the  sum  of  the  effective 
speeds  of  all  the  resources  to  find  the  time  that  the  search  ends  due  to 
the  fact  that  all  the  resources  will  not  be  on  the  scene  throughout  this 
period  of  time,  e.g.,  HH  #1  has  left  and  HH  #2  will  leave  in  1 hour  so  it 
will  not  contribute  effective  miles  past  this  point  in  time.  A possible 
procedure,  in  this  simple  example,  is  to  move  up  to  the  ooint  in  time 
when  the  HH  #2  is  going  to  leave  and  determine  the  miles  left  to  search 
which  is  A30.  vie  then  divide  this  amount  by  20,  the  speed  of  the  boat, 
to  get  24.  The  end  of  the  search  is  24+1  * 25  hours  from  the  present 
time. 
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5. 


Hera  we  have  a similar  situation.  We  move  up  2 hours  which  gives  340 
miles  covered  by  boat  and  aircraft  leaving  130  miles  to  go.  This  value 
divided  by  20  makes  the  end  of  the  search  11  hours  from  the  point  at 
which  the  HH  #1  arrived  back  on  the  scene. 

5.  If  using  the  simple  relationship  refered  to  in  note  4,  we  sum  all  the 
resources'  effective  miles  giving  us  a total  of  270  and  divide  this  into 
the  TSEM  left  to  cover  we  get  a number  which  is  greater  than  1,  HH  #1 
must  leave  in  1 hours,  so  again  we  must  apply  the  procedure  above.  Ooing 
this  we  find  that  the  search  will  be  over  in  2 hours  with  the  total  time 
searching  being  2+5*7  hours.  Interestingly  enough,  besides  the  fact 
that  we  could  not  apply  the  simple  relationship  in  this  example,  the  time 
that  the  search  is  scheduled  to  be  over  is  exactly  the  time  when  the  HH 
#2  must  leave  the  scene. 

Table  3.4.4  A Search  Case  Example 


1 


1 


4.0 


THE  POSTPROCESSOR 


4.1  Overview  Of  The  POSTPROCESSOR 

At  the  discretion  of  the  user,  detailed  information  on 
each  SAR  case  prosecuted  by  the  simulation  and  the  resources  that  participated 
on  these  cases,  can  be  output  to  a file.  Some  of  the  data  contained  in  this 
file  is  as  follows: 


a.  Case  number  and  time  of  occurrence 

b.  Case  weather  conditions 

c.  Case  latitude  and  longitude 

d.  Information  on  the  distressed  unit 

e.  Time  spent  searching,  servicing  demands, 
transiting,  waiting,  and  dispatching 

f.  Queue  information 

g.  Interrupt  information 

h.  Standby  crew  information 

i.  Responding  resource  information  including 
home  station  and  cost. 

To  analyze  this  file,  the  user  may  use  an 
information-retrieval  package,  such  as  IPF  Report  Writer,  to  make  ad-hoc 
reports.  When  the  file  is  no  longer  needed,  it  may  be  purged  or  copied  to 
tape  for  long-term  storage. 

Whereas  the  regular  printed  output  from  the  simulation 
provides  summary  statistics,  the  POSTPROCESSOR  provides  detailed  data  that  the 
analyst  may  analyze.  The  POSTPROCESSOR  allows  the  analyst  to: 

a.  Supplement  the  summary  statistics  so  that  the  results  of  the 
simulation  run  can  be  more  fully  explained. 

b.  Satisfy  users  that  may  feel  that  the  summary  statistics  are 
inadequate. 

c.  Examine  results  that  are  unexpected  or  questionable. 

4.2  Description  Of  POSTPROCESSOR  Data 

As  each  case  is  processed  by  the  simulation,  detailed  historical  and 
computed  case  data  are  collected  and  filed  in  an  output  file  for  subsequent 
retrieval  and  postprocessing. 

The  detailed  data  files  include  for  each  case:  a case  record, 
resource  record(s)  for  each  resource  that  serviced  the  case,  and  a demand 
record(s)  for  each  demand  serviced  by  a resource. 


71 


The  case  record  is  depicted  oelow 


1 2 3 4 5 5 


I 

i 


I 

! 

! 


RECORO  TYPE 

CASE  NUMBER 

TIME  OF 
OCCURRENCE 

SEASTATE 

VISIBILITY 

WIND  SPEED 

7 

8 

9 

10 

11 

PATRON  TYPE 

TONNAGE 

LATITUOE 

LONGITUDE 

DISTANCE 

OFFSHORE 

12 

13 

14 

15 

16 

SEVERITY 

TIME  SLOT 

NEAREST 

STATION 

SERVING 

STATION 

DISTANCE 

TO  SCENE 

, 

17 

18 

19 

20 

21 

STANOBY 

RECALLS 

DISPATCH 

TRANSIT  TIME 

WAIT  TIME 

RECALLS 

UTILIZED 

OELAY 

22 

23 

24 

25 

26 

LOCATE  TIME 

EXCESS 

TIMES  IN 

TIME  IN 

NUMBER 

WAIT  TIME 

QUEUE 

QUEUE 

INTERRUPTS 

Table  4.2.1  orovides  a list  of  the  elements  comprising  the  case 

record  and  gives  an  explanation  of  the  recorded  information  where 

necessary. 

Each  case  record  is  also  accompanied  by  a resource  record  for  each  resource 

serving  on  the  case.  The  resource  record  is  depicted  below: 

1 

2 

.3 

4 

5 

6 

RECORO  TYPE 

CASE  NUMBER 

RESOURCE 

TYPE 

HOME  STATION 

SORTIE  TIME 

SEARCH 

SORTIES 

7 

3 

9 

SEARCH  TIME 

NUMBER 

OEMANOS 

TOTAL  OPERA- 
TING COST 

• * 
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Table  4.2.2  provides  a list  of  the  elements  comprising  the  resource 
record  and  gives  an  explanation  of  the  recorded  information  where  necessary, 
each  resource  record  will  be  accompanied  by  one  or  more  demand  records 
depending  on  the  number  serviced  by  the  resource.  The  demand  record  is 
depicted  below: 

12  3 4 


RECORD  TYPE  CASE  NUM8ER  OEMAIO  TYPE  SERVICE  TIME 


Table  4.2.3  provides  a list  of  the  elements  comprising  the  demand 
record  and  gives  an  explanation  of  the  recorded  information  where  necessary. 
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TA8LE  4.2.1 


ELEMENT 

NUMBER  ELEMENT  NAME 

1 RECORD  TYPE 

2 CASE  NUMBER 

3 TIME  OF  OCCURRENCE 

4 SEASTATE 

5 VISIBILITY 

6 WINOSPEED 

7 PATRON  TYPE 

3 TONNAGE 

9 LATITUDE 

10  LONGITUDE 

11  OISTANCE  OFFSHORE 

12  SEVERITY 

13  TIME  SLOT 

14  NEAREST  STATION 

15  SERVING  STATION 

16  OISTANCE  TO  SCENE 

17  STANDBY  RECALLS 

18  RECALLS  UTILIZED 

19  OISPATCH  DELAY 


CASE  RECORD  DATA 


DESCRIPTION 

1,  indicating  record  is  a case  record 

Case  number  assigned  to  the  case 

Time  of  case  occurrence  (decimal  days) 

Seastate  as  calculated  in  OEM  (feet) 

Visibility  as  calculated  in  OEM  (n.  mi.) 

Wind  speed  as  calculated  in  OEM  (knots) 

Type  distressed  unit  (Reference  3) 

Gross  tonnage  of  distressed  unit 

Latitude  of  case  (radians) 

Longitude  of  case  (radians) 

Distance  offshore  as  calculated  in  OEM  (n. 
mi .) 

Severity  as  determined  in  the  OEM 
(0=routine,  l=severe) 

Time-slot  of  case  occurrence  (Weekday  = 2 
or  Weekend  = 1) 

Name  of  station  nearest  to  the  case 

Name  of  station  providing  the  first 
resource  to  service  the  case 

Distance  traveled  by  first  '■esource  to 
arrive  at  scene  (n.  mi .) 

Number  of  standby  crew  recalls  necessary  to 
complete  the  case 

Number  of  standby  crews  utilized 

Elapsed  time  between  initial  notification 
and  dispatch  of  the  first  resource 


/ 
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20 


TRANSIT  TIME 


Elapsed  time  between  dispatch  of  the  first 
sortie  and  its  arrival  on  scene  or  in  the 
search  area 


21  WAIT  TIME  Elapsed  time  between  initial  notification 

and  arrival  of  the  first  resource  on  scene 

22  LOCATE  TIME  Elapsed  time  between  the  first  sortie's 

arrival  in  the  search  area  and  arriving 
alongside,  i.e.,  securing  the  search 
activity 

23  EXCESS  WAIT  TIME  Time  in  excess  of  input  response  criteria 

24  TIMES  IN  QUEUE  Total  number  of  times  the  case  was  queued 

25 . TIME  IN  QUEUE  Total  amount  of  time  the  case  was  queued 

26  NUMBER  INTERRUPTS  Total  number  of  times  the  case  was 

interrupted  by  severe  case  needs 


TABLE  A. 2. 2 


i 

: 


i 

i 


RESOURCE  RECORO  OATA 


ELEMENT 

NUMBER  ELEMENT  NAME 

1 RECORO  TYPE 

2 CASE  NUMBER 

3 RESOURCE  TYPE 

4 HOME  STATION 

5 SORTIE  TIME 

5 SEARCH  SORTIES 

7 SEARCH  TIME 

a NUMBER  OEMANOS 

9 TOTAL  OPERATING  COST 


DESCRIPTION 

2,  indicating  record  is  a resource  record 

Casa  number  assigned  to  the  case 

Resource  type  as  input  by  the  analyst 
(e.g.,  41UT8) 

Name  of  resource's  home  station 

Total  time  resource  was  on  all  sorties 
(hours)  for  this  case 

Number  of  times  resource  went  out  on  a 
sortie  searching  on  the  case 

Total  time  spent  searching  (hours) 

0 

Total  number  of  demands  for  which  this 
resource  provided  service 

Total  cost  for  the  resource  on  this  case 
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ELEMENT 

NUMBER  ELEMENT  NAME 

1 RECORD  TYPE 

2 CASE  NUMBER 

3 OEMANO  TYPE 

4 SERVICE  TIME 


3,  indicating  record  is 


a demand  record 


Casa  number  assigned  to  the  case 


Oemand  type  for  which  service  was  provided 
Total  amount  of  time  servicing  the  demand 
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